Thanks guys for helping me out here. Thanks NYYRIKKI in particular. I will test your software suggestion tomorrow and report back.
sd_snatcher, apologize for the limited information I gave on this S-100 groups effort. I will go through your comments/suggestions one by one.
First it’s important to appreciate that the IEEE-696 S-100 systems we are using today bare only a rough relationship with the original Altair/IMASI systems. They use the same 100 pin connectors and motherboard but that’s about it. “Modern” systems run Z80 at 10-12MHz, RAM is up to 16MB for use with CPU’s like a 68000 or 80286. I have an 80386 board running with 32MG RAM at 40MHz and hope to do a DRAM board later in the year with 4GB.
There can be up to 16 (different) CPU’s on the S-100 bus, 15 inactive one active at any one time. BTW, the most I have had running so far was 4 (Z80, 6502, 68K and 8086). Software it the limit, not hardware.
As to our MSX effort. We are clearly newbies and it is just one of the branches of the total user group. Personally I’m more into the Linux type 32 bit CPU’s etc. but have been helping out on the hardware for the VDP board. The board, now in its 3 version, has an AY-3-9910 sound chip. The V9938 has four 41464 DRAM chips so I suppose we should call it MSX2 compatible. We are doing a V4 of the board and have already decided to drop the RAMDAC – took us a while to reach the same conclusion!
All our S-100 boards are 16 or 8 bit port IO configurable. On the VDP board we have the AY chip set for 48 & 49H. For the V9938, 90H – 97H.
What I should have mentioned is that another group is doing an S-100 “MSX S-100 Utility Board”. This is to preserve a register compatible MSX engine to support the memory mapper and "slot" architecture. It’s basically a Goldstar MSX computer schematic with the Z80 CPU, TMS9918 VDP, and AY-3-8910 removed. This is a work in process too.
As to general information about the S100 bus…
Z80, as I said, any speed up to about 10MHz, 0-8 wait states (Mem, I/O, M1)
Ports for all our boards are configurable. Should be possible to match most with MSX2.
For Z80 the Monitor ROM is normally at F000-FFFFH. However it can be “shadowed out” yielding a full 64K. We also have circuitry for the Z80 to address 1MG of RAM (0H-FFFFFH in 16K windows).
We boot form a ROM which we all teak for our diverse systems. Code examples can be seen here:-
http://www.s100computers.com/Software%20Index%20Page.htm
Everybody runs CPM. Many CPM3. (I also run CPM86 and MS-DOS V4.01 as well).
We have a Propeller driven “Console-IO” board that takes a standard IBM-PC PS/keyboard and translates the keys (for CPM to ASCII) but is capable of much more complex tasks, translations, strings etc. This is described here:-
http://www.s100computers.com/My%20System%20Pages/Console%20I...
Totally understand the challenge of making “software out of the box” compatible configurations. This was a major challenge for MSDOS with our 8086 family. We have interrupt, timers etc. totally compatible so with our 8086 family of CPU boards we use Microsoft’s MSDOS disks right out of the box.
The goal would be the same for a MSX2 setup.
To boot CPM we built a Z80 driven WD1797 FDC S100 board and an IDE S100 board that can talk to standard IDE drives or CF-Cards. So we have floppy and “hard disk” CPM versions already running. These and other boards are all described in detail on the S100Computers.com web site.
The major asset of the S100 system is that all hardware components are completely configurable, with each on a separate board. This not only allows one to stepwise build the system but it makes hardware debugging much easier. The systems are very robust. My 80386 S100 board running at 40 MHz with 32 MG of RAM and is pounded by interrupts from the timer; keyboard etc. yet never drops a byte!
So I’m not worried about the hardware, it’s the software I having problems with.
Hope the above is of some help. MSX(2) users if you have more questions please feel free to ask.
Thanks for all the information! Now I have a somewhat better idea of how the S-100 computers are structured and how you plan to implement the MSX compatibility.
Here are some new tips based on the information you gave. It will help you to shorten the development time and avoid some known caveats.
Caveat: Your Z80 boards certainly run fast than the standard MSX speed (3.57MHz, 1 wait state). That will cause them to write too quick on the VDP and data will be lost.
Possible Solution: Generate forced wait states on I/O to hold the speed within V9938 limits. But just don't hold it too much, otherwise the slower speed will cause glitches in many games that transfer a lot of data to the VRAM, like the game Fire Hawk. Keep in mind that the limits are different for register and VRAM access. It will be good if your VDP wait state generator is flexible enough to couple with faster Z80 speeds, as you'll notice that the turbo is very welcome in many MSX games.
Caveat: The original Intel 8255 PPI can take I/O only up to 5MHz. But there are compatible chips from other makers that support much more speed.
Tip: There's a 82C55 from Thundra that supports up to 10MHz I/O.
Caveat: Your keyboard is very different from the MSX one. I had a quick peek on its schematics. It seems powerful, but I'm not sure if it will be capable of emulating the PPI keyboard interface because it's based on register latches.
Possible Solution1: The simpler/cheaper possible solution is software based. The MSX standard allows the keyboard interface to be completely replaced if you rewrite the BIOS keyboard routines to abstract the difference. In this type of solution, your console I/O board would act much like the i8042 in the PC-AT architecture: it will read the serial data from the keyboard, and generate interrupts providing parallel data to the CPU. Although perfectly designed in compliance with the standard, this solution has one caveat in itself: some games ignore the MSX coding guidelines and directly access the 8255-PPI I/O ports. Those games will have to be fixed to run in your hardware.
Possible Solution2: The more expensive solution would be to use your console board to emulate the PPI itself. This will be quite a challenge, since (1) your console board doesn't seem to support the I/O protocol used by PPI and (2) You already have a PPI in another board that you called "MSX S-100 utility board". And both PPIs will not be able to coexist into the same I/O port.
Tip: Your primary first objective should make the MSX-BIOS boot and work properly. From that point you will be able to build everything else. It will also be very easy to test things using MSX-BASIC commands. You'll have to patch the BIOS to match the I/O ports you have chosen though. That should be very easy for any experienced Z80 programmer.
Tip: If you need the MSX-BIOS disassembled sources, take a look at the msxsyssrc project on SourceForge. The many modules for specific devices will be there too. For example, you probably will have to build a custom driver for your disk interface.
Last, I have one doubt: How do you plan to integrate your system RAM with the MSX slot switching mechanism done by the 8255-PPI?
Thanks for the input/suggestions sd_snatcher.
As to Z80 speed, I can easily add a wait state generator (1-8 wait states) to get the V9938 down to ~3.75MH speeds. Could make it so only chip I/O’s are slowed.
We use 82C55’s (at 10MHz for our IDE drive board).
The keyboard interface can be interrupt or status bits driven (or both). The onboard Propeller software on the boards ROM can be programmed to run rings around an i8042 PC-AT style setup. There would be a problem however if the MSX software goes directly to the 8255 PPI ports. Are there a lot of games/software that take this shortcut?
On your last point MSX slot switching, I have not looked into that one, the “Utility board guys” have that one! However remember our Z80 board has two 16K dynamic windows that can move any RAM from 0 to FFFFFH (1MG) temporally into the first 32K of RAM.
The above did not make any difference. See here (bottom of the page) for a picture of the output:-
http://www.s100computers.com/My%20System%20Pages/VDP%20Video...
Since the duplication starts on the RHS on the middle line, I'm suspecting the problem has something to do with how much RAM the chip thinks it has or how the characters are mapped as apposed to a hardware problem where you might expect the duplication to be on the LHS directly under the top text.
Any chance you could run the code directly on an MSX box and see what you get.
The .zip file on the same page has the source. The .COM file is in CP/M format set to run at 100H. Keyboard input however is hard wired and will not work, but the video should work!
John
@monahanz: hi, about VDP addressing have you considered that there are two others address used in msx2? they are:
$9B => auto-increment register port (write and initialize a block of registers, used by some msx2 sw)
$9A => palette, also used from games to simulate fade-in fade-out or others effects by changing palette
Also you probably need to take in account that the vdp delay is different in active area than on vertical interrupt. Games rely on this, unfortunately. On active area a single data-output cannot be more frequent than about 4us. in inactive area/screen disabled should be 2us. the v9938 unlike the v9958 does not provide hw handshaking ( a wait signal )to avoid too fast writes.
@monahanz
Have you initialized the VDP R#8 properly? There's a bit there to select between 16K or 64K DRAMs.
Another tip: Download openMSX and openMSX-debugger. This emulator has an excellent debugger that allows you to check the contents and play with the V9938 registers to your heart content. It will certainly help you to figure things out.
Here is what I have for R#8.
INC E ; To Register #8
LD A,09H ; *** (00001001) = no mouse,no LP, set color code,color bus output mode,
; VRAM = 64K , 0, Sprite disable, Set to B&W
OUT (C),A ; *** Send 00001001
OUT (C),E
Does it look right to you. Bit 3 (VR) is set to 1 for 64K.
Is there any way to test this "software" on somebody's system. That would tell me a lot. I'm still worried there is a hardware layout problem. The CP/M program can be downloaded here:-
http://www.s100computers.com/My%20System%20Pages/VDP%20Video...
near the bottom of the page.
I tested it on openMSX, emulating a Sony HB-F1XDJ and MSX-DOS. The result was a completely black screen.
OpenMSX-debugger complains that the pattern name table has an invalid value. I guess that this is what's causing the mirroring. It also happens on other screen modes, and for the patterns generator table such mirroring is using to achieve the so called SCREEN1+2.
These are the differences between what the V9938 registers had before and after running your program:
R#1: 0x70 -> 0x50 R#2: 0x03 -> 0x00 R#4: 0x02 -> 0x01 R#8: 0x08 -> 0x09 R#9: 0x00 -> 0x24
BTW, the message "VH9938, VIDEO DISPLAY (80 X 24 Characters/Line - TEXT MODE 2)" is being written on 0x00690 on the VRAM, when it should be written on 0x00000.
openMSX guys: How to I redirect the output of the command "vdpregs" to a file? (or any console commands, BTW)
That somewhat reassuring sd_snatcher. Thanks. I would have been more worried if the display was fine in your hands.
I'm still trying to understand the MSX terminology!
The "pattern name table" I'm assuming is the screen display area.
For 80X25 where should this start at. Currently I have it at 0H (0H-> register #2)
The "pattern generator table", I'm assuming is what would be normally called the” ASCII characters ROM table”.
It looks like from what I'm seeing the character bits are the same as on the original IBM-PC, so I used them.
It’s unclear how and where these should be located for 80X25. At least for 40X25 resolution sending 1 to register #4 works. (well at least partially works, I cannot quite figure out how to display character decenders (like “y”,”q” etc.) to display.
I there any way you could modify the program (I think the code is straightforward) so you could get for me 80X25 in your system. With that working I would be in great shape on my end.
You can send the ASCII .z80 file to monahan AT vitasoft.org (no spaces, AT->@).
I'm still trying to understand the MSX terminology!
In fact, this terminology is inherited from Texas Instruments' TMS9918. It will be present on any machine that use this VDP or any of its derivatives, like: Colecovision, Sega SG-1000, Sega Master System, Sega Mega Drive/Genesis.
The "pattern name table" I'm assuming is the screen display area.
For 80X25 where should this start at. Currently I have it at 0H (0H-> register #2)
I'm not experienced in screen-0, but my guess is that writing 0 to R#2 is what's causing the mirroring you have been experiencing. Just write 3 to R#2.
The "pattern generator table", I'm assuming is what would be normally called the” ASCII characters ROM table”.
It looks like from what I'm seeing the character bits are the same as on the original IBM-PC, so I used them.
The screen-0 uses 6x8 characters. AFAIK, the IBM-PC set is 8x8. So those characters will be a bit too large and will be cropped.
It’s unclear how and where these should be located for 80X25. At least for 40X25 resolution sending 1 to register #4 works. (well at least partially works, I cannot quite figure out how to display character decenders (like “y”,”q” etc.) to display.
The registers will be decoded into addresses. You should really try openMSX and openMSX-debugger. The debugger has as excellent register-view feature that will easily decode all those addresses for you, and it's much easier to understand than the V9938 data sheet. Just take a look at this screenshot:
![]()
So, to check the correct values you just need to boot an MSX2 in openMSX, type the commands below in BASIC, and connect the debugger to it:
SCREEN0 WIDTH80
Then, just use the debugger to check the addresses and see where you should load each data.
Screen-0 uses just two of the tables:
- Pattern Name table (aka name table): It's the vector that contains the ASCII text to be shown on screen
- Pattern Generator table: Contains the 6x8 bitmaps for each character.
