Home Page Forums MAME MAME Requirements?

Great, thanks for the info on the tables! That should make it easier to figure out how the 6805 program works

Hi everyone,

I think I can help with the LK201 as I have both the 8051 and 6805 variant PCBs here. I also have an EPROM programmer so I'll read the 8051 in at some point. However I've traced the wiring on the 6805 PCB and I pretty much know which pin goes where now. The keyboard matrix is the same for both variants. I've made a start on modifying dec_lk201.c and have got this at least partly working with the VT220. I've added the input ports for the keyboard matrix, the code to scan it, the code to drive the LEDs and some of the code for the SCI and SPI interfaces. I've tried joining it to the Rainbow but I'm having some difficulty working out how to (correctly) use device_serial_interface. Also the bytes being sent out via port 0x10 to the 8251 UART do not seem to be keyboard commands? Perhaps I did something wrong? I think between us we should be able to get this working.

I metioned the VT220, this is actually where I started. There are two variants of this: one with an 8051, two program ROMs and a character ROM and a later variant with an 8031 and a single program ROM. I have started implementing the earlier variant as that is the one for which documentation is available. It currenly passes about 20 of the (?) self tests, but the LK201 is going to be needed so I started looking at that.

I guess the next step will be to send some diffs to someone and hopefully they can help me with device_serial_interface and hooking this up to the rainbow to test it properly.

Matt

Matt: that's awesome! PM me and we'll figure something out

Great news, Matt ... I just got a nice VT320 off Ebay for 20� ...couldn't let it pass ... now things like the P112 board are working in style

I have a vt320 here, getting the roms out to dump those looks to be a gigantic pain in the ass, they're in a metal cage which seems to be soldered to the pcb, underneath the tube.

I also have a C.Itoh CIT-220+ which looks like it might be using stolen vt220 or vt320 code, unclear. It uses some very odd chips for graphics control, though everything is standard JEDEC ROMs for actual character sets, main code, etc. I have it fully dumped, including the keyboard MCU. (and I have to thank Kevtris for desoldering all 125 keys from the keyboard in order to facilitate repairing it, which is now done. Someone had spilled coffee into it years before I got it and it wicked up into the key contact leaves of most of the keys, so pretty much nothing worked) The C.Itoh keyboard is far more repairable than the LK201 is (usually lk201s get scrapped when they die because the membrane goes bad) and uses real spring+leaf switches for the keys rather than a membrane like the LK201 does.

LN

Hi LN,

looks like we have got the ROM ... it's 23-054E7 in this directory:

http://www.dunnington.u-net.com/public/DECROMs/

and the pcb pic at

http://www.vt100.net/dec/vt320/pcb

shows one ROM.

Robert

Rainbow.c: i now have a clue why MS-DOS 2.x crashes (and CP/M 1.1 boots).

One reason is that our interrupt handling looks incorrect. There is additional IRQ logic not reflected in our code.

Please see the attached image in my Dropbox:

https://dl.dropboxusercontent.com/u/37819653/SH_6_VECTOR_SELECT.jpg

The screenshots are taken from the Field Manual of the PC-100 B, and the vital clue came from RBCONVERT.ZIP (File: CONVERT-A-B).

Next thing is the wrong sector interleave (1:1) instead of the following (sector count from 0 to 9):
LOG. => PHYS 0, 2, 4, 6, 8, 1, 3, 5, 7, 9
PHYS. => LOG. 0, 5, 1, 6, 2, 7, 3, 8, 4, 9

This is valid for both CP/M and MS-DOS; only for tracks >= 2; counted from track 0.

Please advise what to do.
The current code base is increasingly difficult to understand.
Help is appreciated.

Incorrect interleave shouldn't matter; software requests a specific sector from the FDC and it will fetch that sector. It's only a problem if the sectors in the image file aren't in the order the parser thinks they are (for instance due to a format that doesn't preserve that information).

The interrupt vector thing is interesting; what other hardware differences are there between the 100A and 100B?

A comparison...

RAM ADDRESSING / SIZES
> fixed 64 K RAM on board (instead of 128 K on board of PC-100 B)

> a maximum of 832 K RAM -with RAM extension board - (instead of 896 K on 'B')

ROM
> ROM 04.03.11 (for PC-100-A) in 3 chips (type 2764)
FA000-FBFFF (E89)
FC000-FDFFF (E90)
FE000-FFFFF (E91)

> PC-100B / PC100B+ has ROM 05.03 in 2 chips (type 27128) at memory addresses:
F4000-F7FFF
FC000-FFFFF

ROM DIFFERENCES (derived from my latest ROM disassembly)

(*) PC-100-B only. Not present in original PC-100 specification from March 1983.
0x1a and beyond are marked as 'reserved' there.
There is no documented way to emit bell sounds on the Rainbow 100-A (confirmed in Jeff Armstrong's blog). No hardware limitation of course: the beeper sits in the keyboard.

The 'A' model did not come with a hard disc, and there were no provisions in the old ROM to boot from HD directly.

LIMITS WITH OPTION BOARDS

GRAPHICS (when using uPD7220 Graphics option)
> limited graphics palette: 4 colors where with the B board you get 16.

80286 ACCELERATOR BOARD
> Suitable Solutions 286 accelerator board runs in either a 100B or a 100+, but not a 100A.

Note that i own neither a 100-A nor the fancier option boards. I am also more into software than hardware. Feel free to correct me.

SVN #27909 has IRQ management (I have no idea what the priorities are when more than one is signaled at a time but that can be easily adjusted) and the keyboard 8251's DTR line is connected to bit 7 of the IRQ vectors.

Let me know if that helps