Hacking Basic
I/O Map
What you can see in the picture above is my current version of the 4951C I/O map.
As you might know, the device is Z80 based (a NSC800, which is a Z80 with an 8086 compatible bus interface) and a Z80 has one memory and one I/O space.
The IO space is 256 bytes wide and created by some really nasty 74LS-logic spaghetti.
IO Timer Chip
Many peripherals are controlled by the IO-Timer chip NSC810.
It has two 16 Bit timers used to provide some signal timing based (for the capture data) , but also to interrupt the CPU regularly.
More interesting for the moment are the PA0…7 and PB0…7 and PC0…4 interface lines which control a lot of aspects of the system.
Some IOs control the very extensive memory paging (due too the limited 64KB address range of the Z80), others some CRTC or floppy functions. Details in the table above.
Interrups
This is really quite simple as you can see above. The SCC is the serial chip connected to the PODs which is very versatile. The floppy controller is a fully fledged 8080 CPU based subsystem, which I still did not analyse.
The keyboard request only reacts to some of the function keys since they can interrupt also running applications (the rest of the keyboard is polled by a timer interrupt).
One thing to mention is that most of these interrupts are latched and synchronised to the system clock, so you will have to manually reset these latches.
Memory Map
Most complex is the memory map and the layout of the specific ROM/RAMs in the address space.
The page rom is at position 0x0000 and positing 0x2000 and the pages are always selected together. The 0x0000 to 0x1FFF space is always “paged in” as a lot of low level system code is here. Also all the interrupt vectors are in this space – in reality pages 0…3 contain a copy of the same code.
The CRT Buffer is the so called dual port ram (in the documentation) and is not only used for the CRTC, but also as usual RAM.
The application ram segment 3 can be mapped instead of the second page of the page rom, which sometimes is done to buffer some RAM during system startup.
One special case is the Mass Rom which contains the floppy disk interface code. It automatically selects the two app ram pages into the address space….I guess because the disk controller uses this as DMA target to communicate with the Z80 CPU – but that’s only a guess so far.
POD Interface
Actually I started my investigation at the POD interface. My idea was maybe to create some new, custom designed PODs with a to be loaded application.
So here we go with the POD interface:
Generally speaking the SCC controller is connected through some multiplexers to the respective POD outputs. The multiplexing is used to simulate DCE or DTE.
But there are also D0-D7 on the POD cable which also can be used more freely.
Please note that D4;D6 and D7 are used to identify connected POD. No POD means all high, my POD pulls all low.
What’s next?
I hope my spare parts will arrive soon that I can put the cutie together to prove some of my hypotheses with a logic analyser.
I also started to disassemble the ROM-P – this is a really lengthy process even for such a tiny ROM.
But getting in a position to write apps, there is no other way ;-(.