NEW: Dossytronics 65816 Tube and FIXES to debugger

[dominicbeesley]

Hello, here's some changes I made to bring this in line with the newer PiTubeDirect 65816 stuff. I'm still actively working on the client rom so this will probably be updated in the coming days.

I'm afraid I'm a GitHub Luddite and I've managed to get the visual C project file tweaks in with the pull request. I can't figure out how to remove that.

Also, I'm not sure if the .rc file and resources.h files actually needed to be changed - are they actually used still?

NEW: 65816 tube Dossytronics added FIX: Hoglet fixes for banking and xce back ported from PiTubeDirect FIX: Debugger opcode &DD gave (IND) addressing mode instead of ABS,X FIX: 16 bit immediates for index and A registers had bytes swapped

[SteveFosdick]

Oh, and the menus in the old Windows resource format are not used in the current version. They date from when Windows and Linux had completely different UIs. The latest UI is allegro one gui-allegro.c

[SteveFosdick]

Also not I have pushed another commit to fix not propagating the return value from the original init function w65816_init to the return value of w65816_init_dossy and w65816_init_recoco. This was flagged by a gcc warning when I checked it still compiled on Linux.

[dominicbeesley]

Thanks Steve,

Do you mean a link to a stardot thread? If so we're kind of on this one: https://stardot.org.uk/forums/viewtopic.php?f=2&t=21159&p=300459&hilit=65816+basic#p300267

If you mean for the Tube OS rom source, I've not started a repo for that yet but there's a copy of it in the PiTubeDirect: https://github.com/hoglet67/PiTubeDirect/tree/gecko-dev/src/65816/tuberom_dominic

I'll start a proper repo for the 65816 TUBE project but I need to figure out how it will fit in with other projects first

Or the original tube hardware: https://github.com/dominicbeesley/65816_tube_altera

I've spotted a few more errors in the 65816 core emulation in b-em, I'll try and collect these into a bigger pull request some time later this week. I'll liaise with Hoglet, BigEd and the other 65816ers before I bother you again.

One question? A while back I added a function to spool a binary dump to work with Hoglet's 6502decoder. I can't remember if that ever made it on to the upstream/master. It would be a very useful adjunct to the debugger - would it be ok to add it again?

D

[SteveFosdick]

Thanks for the links. On the binary dump I wonder if I inadvertently removed it. Or maybe it was on one 6502 and not on the other (the tube 6502 is a copy/paste of the other but then they diverged).

I also remember adding a binary trace to the 6502 but my thinking was that it was superceded by the text version. The issue was that to extend this feature to all co-processors each would have to have their own binary formats and their own external decoders. As all the co-processors have had a disassembler added to b-em it seemed like less maintenance not to duplicate that.

On the other hand, if external decoders exist, or are being written, anyway for more general use then having b-em able to write a binary trace file seems perfectly sensible. There is no so much code at the b-em end, most of the effort is in the decoder.

If we made it generic and able to be enabled a run-time then we would probably need a function per-co-pro to enable it as the detail of instructions being fetched from memory is not exposed. This could be another element of the cpu_debug structure, The debugger could open/close the file and then pass it (or NULL for disable) to the new function. Then each CPU implementation then needs to write the file in whichever format the decoder expects.

[dominicbeesley]

Thanks Steve,

The debugger dump thing is useful (and I have been using it) but I have a load of scripts that hang off Hoglet's thing which are useful when there's a problem that is hard to catch using normal debugging. Sometimes I end up streaming a huge amount of data to find where some code goes off piste.

I'll have a look at the other processors and see what is sensible for them, I suppose it could be enabled on a processor by processor basis.

I've got a few tweaks for the 65816 but I'll save them up and do a pull when I get a bit further with the 65816 client ROM - it's coming on but I've got distracted by a few other things and real life so might not be this week

[SteveFosdick]

Dominc, I have found the bit I vaguely remember removing. In the initialisation for the Tube 6502 only, there was this:

#ifdef TRACE_TUBE
         if ((trace_fp = fopen("6502tube.trace", "wb"))) {
                 fwrite("6502NMOS", 8, 1, trace_fp);
                 time_t secs;
                 time(&secs);
                 fwrite(&secs, sizeof(secs), 1, trace_fp);
                 puts("tube tracing enabled\n");
         } else
                 fprintf(stderr, "tube6502: unable to open trace file: %m\n");
 #endif

But this was essentially already an orphan piece of code because, even if compiled in, nothing was writing to trace_fp. This piece of initialisation was removed by commit: f1865de68833f4265aa4f1c4d235a739cb2162ce. I am also not convinced this was a version to work with Hoglet's 6502 decoder.

I agree that with Hoglet's decoders it is worth adding binary tracing back in. If you still have the code could you put in a pull request for it?

[dominicbeesley]

Sorry Steve, that was me misremembering - the hoglet dump thing only worked on my blitter branch where I'd grafted the mame cpus instead of the standard 6502/6502tube - the hoglet dump needs a cycle accurate dump of each access which I didn't work out for the real cpu.

Sorry to have confused things - I'll be back in touch (in the distant future probably) when I've revisited the cycle accurate stuff I was experimenting with. It was slower than the current emulations but not by enough to rule it out.

D