Debugging suite for 'unexpanded' PAL-1

[D Hassler]

Hi, group.

I've put together all of my little debugging tools into a package called LIL' BUG.  Total size is 2.25 KB, so it's appropriate for users of 'unexpanded' PAL-1s and microKIMs.  Included in the package are the following: copy memory, fill memory, a hex/ASCII dump, register printer, search for byte sequence, and the Woz/Baum 6502 disassembler ported for PAL-1.  Load and run the PTP file (found on my github: https://github.com/fishhack66/PAL-1-Stuff) at $0B00 to get started.

Also included is "eWozLite", a stripped down version of eWOZ with the input buffer moved to the top of memory (instead of at $0200) and the Intel hex loader removed. This allows the examination of data and programs that use RAM contiguously from $0000 to $0AFF  (and if eWozLite is run by itself, to $121F).  Of course, feel free to examine any range of RAM or ROM you have!  :^)

All of the separate modules -- object and source -- are available, too, so you can "roll your own" and tinker with individual pieces.  Full documentation is there, as well.  Thanks to Nils Andreas for the hours of testing!

Best regards and have fun!

Dave

[GN L]

Thank you very much for the work! It is handy~

Best,
Liu

> --
> You received this message because you are subscribed to the Google Groups "PAL 6502 computer" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pal6502+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/pal6502/3f61b6e4-39b1-426e-95af-87a3b9dda410n%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Neil Andretti]

Lil' Bug  -  A great set of tools for the unexpanded PAL-1.

Good work, Dave!

Thank you

[Jim McClanahan]

For those who haven't played with eWoz, one of the nice things is that the format of the hex dump is such that if you capture it in a text file you can later replay it and use the dump to reload memory. This is a pretty handy feature and not having the Intel hex capabilities really isn't much of a loss for most uses.

I think I've used the Python program I used to convert Intel Hex files to the right format to load in Lee Hart's 6502 badge to generate files that can be loaded by eWoz also. That can be found here:

https://github.com/w4jbm/6502-Badge

(If someone tries it and it doesn't work, let me know and I'll tweak it as needed.)

The one thing to watch for is that when eWoz is loading, it loads the ASCII line into a line buffer and then processes it when you press enter. That means that it tends to need a bit more of a pause after each line than something like the KIM's monitor (which processes each character as it comes in and needs a bit longer pause between characters but not much of a pause at the end of line).

Thanks,

Jim W4JBM

[D Hassler]

Indeed, there's more "overhead" with eWOZ (and eWozLite) when uploading text files, versus the terminal interface monitor in the PAL/KIM.  I'm using a 10 msec char delay and a 200 msec line delay, and I get solid uploads (usually send PTP files at -5, -100 via the TIM); any faster upload and it misses data.  I also find that the Apple I hex format is very easy to patch "live" with eWozLite (along with LIL' BUG or any other tools of choice) when I'm working on something.

The only other thing to add is that for assembly, I write source code on Mousepad (XFCE on Linux), then paste that into the online 6502 assembler at https://www.masswerk.at/6502/assembler.html.  It's sort of Commodore-centered, but the default output is straight-up A1 hex.  And it's quite forgiving of my simple source formatting.  I just copy the output of the assembler to a text file, then upload that into eWOZ/eWozLite.  The whole process takes about 15 sec plus upload time, and then Bob's yer uncle.