Memory mapped video & WiFi & Terminal Emulator - blog post

[Rob Dobson]

Hi All

Just thought I'd let you know that I have done a lot more work on the memory-mapped video card I mentioned in a previous topic.

There's a blog post about it here: https://robdobson.com/

Currently there is emulation of memory mapped video for:

- TRS80

- ZX Spectrum

- Rob's Computer = 512 x 256 mono bitmapped video

There's also a terminal emulator mode which is similar to the Pi Zero Serial Terminal board but doesn't currently support the VT100 terminal escapes

There's also WiFi which allows programs to be downloaded directly to the RC2014 by drag-and-drop / upload - currently this works ok for simple situations like some TRS80 game but some more work is needed to support situations like ZX Spectrum games loaded from tape/tape-emulation/snapshot files - maybe someone would like to have a go at this?

And a clock generator which attempts to create the right speed of clock for the machine that the graphics is emulating - e.g. for a TRS80 that's 1.7MHz

I have a few extra PCBs and would be happy to send one to each of the first 5 interested people.

All the code and PCB designs are linked through the blog post.

Rob

[Alan Cox]

As an old ZX spectrum game programmer there are a few things I think
you are going to have fun with and which your blog doesn't really
touch on

1. Most copy protection was done at the tape level and in the tape
loader. As you are using a real Z80 and not doing stuff like patching
and stepping the code in a debugger all the stuff that plays with
illegal instructions and undocumented flag bits is going to be fine -
unless someone is using the undocumented out (c),255 in which case
you are only going to get the right result with an NMOS CPU. AFAIK
nobody ever did that. At the point you are loading a snapshot you are
already good except for a couple of slightly mad games which didn't
work with even the hardware snapshot NMI devices because they were
written to keep the stack pointer in ROM and never used the stack ! In
other words if your snapshot worked on an emulator I doubt it's copy
protection btreaking it on your setup.

2. You will need a vblank interrupt and all your I/O cards to decode
IM2 cycles on the bus correctly, because many games stick the CPU in
IM2 and point the i register at 257 consecutive identical bytes in
order to steal the vector from the ROM

3. Many of the later games require cycle perfect timing for the
graphical effects and to avoid flicker. Even with emulators it's
really tricky to get right.

4. Some games require the current attribute colour is correctly
reflected on an I/O port as the video output scans (eg Arkanoid)

The trash80 ought to be a lot easier as there was a lot less use of
such trickery, and things had to be more portable anyway back then.

Can it in theory handle banked memory (eg can it spy on enough to work
with a 512K RAM/ROM to emulate a tras80 with a supermem or similar ?)

And I like the UI/wifi download - the M4 for rhe Amstrad CPCs has that
feature and it's brilliant.

Alan

[djrm]

Hi Rob, I've seen your earlier efforts on the group here and I'm very impressed. I like the idea of memory mapped screen driver and your design has an elegant simplicity. I'd be interested in building one of your spare boards of you still have one available. I've just about got enough spare rc2014 parts now to make another system now I've upgraded to romwbw. Kind regards, David.

[Rob Dobson]

Hi Alan

Thanks for these thoughts. I don't think I will be able to find the time to look at the Spectrum support any further and I'm really hoping someone will pick up the gauntlet on that one.

The paging support should work as it is possible to read/write any IO or memory location and it is also be possible to interrupt on any IO (or memory for that matter) access. If the paging system uses write-only registers (which it looks as though the 512K ROM / RAM does) then it would be necessary to track the latest page by intercepting all IORQs and interpreting the ones that mattered so that the state could be restored after any intervention (such as dumping program/data into a page using a BUSRQ cycle).

BR
Rob

[Rob Dobson]

Hi David

Drop me a line at Rob at Dobson dot Com with your address and I'll send you a PCB.

BR

Rob

[Conrad Larsen]

Hi Rob,
I just read though your blog, Raid the Bus and the Speccy Lives! And very impressed. It has some great ideas to get my head around.

Conrad

[Rob Dobson]

Hi Conrad, I've started selling these on Tindie https://www.tindie.com/products/robdobson/busraider-graphics-debug-kit-for-rc2014/

[Rob Dobson]

Hi David, I've started selling these on Tindie https://www.tindie.com/products/robdobson/busraider-graphics-debug-kit-for-rc2014/

[Richard Lewis]

Hi Rob,

I've built your busraider card and I'm in the process of setting up the Pi. The manual states there are 4 files: bootcode.bin, start.elf (which are part of the standard pi distribution), kernel.img (which is in your repo PiSw/bin directory), and config.txt which I can't seem to find. 

-regards

Richard

[Rob Dobson]

Hi Richard

Thanks for spotting that. I've pushed that file to GitHub now (in the PiSw/bin folder).

There is a new software update (for both Pi and ESP32) which does a better job of single-step debugging (still not perfect but coming on well) and reading some Spectrum formats (.Z80 and .SNA).

 

If you could let me know what aspects of BusRaider you are most interested in it would help me prioritize development. For instance, are you most interested in:

 

• Playing retro games – if so from which machine(s)
• Running business software like CP/M and RomWBW
• Single-step debugging of software

 

Also any info about hardware you have would be great to know. For instance, the single-step debugging works only with a page-able RAM board and I’m working to get the 512K RAM/ROM paging mechanism implemented.

 

Do let me know how you get on and if you have any issues.

Best

Rob

[Alan Cox]

> Playing retro games – if so from which machine(s)
> Running business software like CP/M and RomWBW
> Single-step debugging of software
>

For me I'm watching it for two reasons

1. When it can do pageable RAM tracing to be able to use the single
step to collect bus traces (ie I'm not interested in single step
itself but continual single stepping or just bus tracing directly to
generate a log of everything I can then postprocess with symbol tables
and whatnot to see why my code exploded and where.

2. Frame buffer once it can track 512K RAM paging so the framebuffer
can logically exist in a particular page. Format doesn't matter too
much. I'd probably just hack myself a 16K linear bitmap for 640x200
mono 32x200 4 colour 160x200 16 colour something akin to the Amstrad
CPC without the weird bits

[Richard Lewis]

Hi Rob,

For me:

1. I have a lot of TRS-80 software on cassette and 5.25" floppy which has probably disintegrated after 40 years but want to attempt to rescue it.

2. Support for the Level II ROM and eventually the Model IV 

3. I also have a reasonable emulation of the RC2014 ecosystem written in VHDL (sans the SIO chips which are difficult) running on Altera and Xilinx FPGA's. It can be found here in my github repo: RC2014_fpga. I'll write up instructions for it sometime today. It's a WIP but will run any ROM that bootstraps the 6850 UART. This week will work on hooking up the CF card so I can boot CP/M.  I am planning to build a RC2014 bus adaptor between the DE10-Nano and DE10-Light boards and looking toward busraider a means to debug the bus interface (along with my salae logic analyzer). 

-Richard

[Richard Lewis]

Replying to my own post, what I meant to add:

3. ...  So I would like to be able to interface my FPGA board with the Busraider since the 5V to 3.3V level shift is available. The upper part of the board with 2x15 unused pins looks ideal for this. My goal is to interface my board to real hardware (such as the SIO/2) and not have to breadboard level shifters for the bus. Also would be cool to use the Busraider do debug my emulated hardware. 

4. I know real estate is tight but an ADC so I can hook up a cassette interface. 

[Rob Dobson]

Richard

Thanks for your feedback. Regards your wishes:

1. Not sure I can help a lot with this but see my comment to 4 below

2. Yes, that's something I plan to work on soon(ish)

3. Sounds interesting, I think BusRaider should help with debugging ... it's still a work in progress but I'm getting more consistent debug results and hope to have something really good soon(ish). I think interfacing your hardware might be ok as you describe but the level shifting in the BusRaider is turned on/off in software to multiplex the address low/high and data bus onto a set of 8 Pi pins - so the shifting isn't constantly on which might be an issue.

4. The ESP32 has ADC capability. The software for that is also in the repository and might be considered more approachable as it is regular "Arduino style" code and isn't particularly timing heavy as it doesn't have to do anything real-time with the bus.

Do let me know how you are getting on with your BusRaider :)

Best

Rob

[Rob Dobson]

Hi Alan

Thanks for the comments. It is very useful to have some additional thoughts about where to focus. In response to your points:

1. I've recently actually added something like what you suggest in order to track IO operations so that I can work out exactly how some software is functioning. MREQs are also trappable and loggable in exactly the same way. The method I'm currently using is to drop down to a reduced speed when in debug mode (currenly 500KHz) and this makes the rate of production of IORQs workable for most programs I've tried. It would probably be necessary to drop the speed further to log all MREQs as the only way to get data out from the Pi is a 500K baud serial interface to the ESP32 (and then up to somewhere over WiFi - or maybe to SD card). Actually I have been looking at some code to access the Pi's own SD card recently so that should be faster I guess. But in any case what you suggest should be possible. Do you have in mind a format for the log file you're thinking of?

2. I started working on the 512K RAM/ROM card paging scheme yesterday. It is pretty straightforward and I've implemented the code to track the pages and to page the card out when injecting opcodes for register grabbing, etc. However, I haven't attempted to build an image of the pages in the "shadow-RAM" that is maintained in the Pi. It wouldn't be difficult to do this and then any chosen page/location could be used for the memory-mapped framebuffer. Also the Z80 Debug VS Code add-on that I'm using doesn't directly support paged memory but it does re-query any memory that it displays at every pause/step so if a page was switched you would see it happen in the UI which is quite nice I think.

Based on your suggestion I will take a look at 2 and should be able to build that into my thinking for supporting the 512K RAM/ROM card. I could also take a look at 1 if you let me know what format and where you'd like to log the information.

Best

Rob

[Alan Cox]

> Based on your suggestion I will take a look at 2 and should be able to build that into my thinking for supporting the 512K RAM/ROM card. I could also take a look at 1 if you let me know what format and where you'd like to log the information.

With emulators I normally capture A0-A15/D0-D7/M1/IORQ/WR and then
throw the lot through some scripts that break it down by instruction
and data read/writes. Some day I'll add a disassembler to it but I can
read most Z80 without so it's always been a TODO item 8)

I'm not really too fussed what format it ends up in. It's going into
something anyway.

Alan

[Rob Dobson]

Hi Alan,

I've been working on a variety of aspects of the BusRaider in the past week and found it more and more difficult to keep all of the modes of operation working. The project has been without a test harness to give more confidence when changes are made and I hadn't worked out previously how to viably create such a thing.

But I'm wondering if your RC2014 emulator might be (part of) the answer.

I've pulled in the CPU emulation so far and I'm working on an instruction by instruction comparison of the real and emulated systems. Early days so far but it would be good to know if you have any thoughts on this approach and how realistic it might be to pull the rest of the emulator in.

Rob

[Alan Cox]

> I've pulled in the CPU emulation so far and I'm working on an instruction by instruction comparison of the real and emulated systems. Early days so far but it would be good to know if you have any thoughts on this approach and how realistic it might be to pull the rest of the emulator in.

At the CPU level it should be perfect. If you ever find a difference
I'd like to know. There are some really crazy corner cases involving
undocumented flag bits that libz80 doesn't emulate (some of which
aren't even the same between Zilog and NEC parts...) but otherwise it
should be exact. So the only differences I'd expect would be that push
af data pushed might vary on bits 3 and 5.

The rest of the emulation depends what you are trying to test. The
timing of things like interrupts are not cycle exact - for one because
I've got no way of measuring things like exactly how many clocks after
an SIO write the IRQ asserts.

Alan