What if? Designing "Geneve 2020". Cool 3D views!

[+9640News]

As far as XOP's and interrupts, please keep in mind programmers have approached multiple routes for some of their programming.  Some programs using the XOP's to do/get video data and keyboard data, while others go straight to the ports and bypass the XOP's all together.  Some even mix things up depending upon the needs or what worked for them at the time.  I'm not sure how your "Supervisor mode" would interact in these situations.

 

Your first task should be to get an unmodified latest version of MDOS running.  If you accomplish that, then everything else is bread and gravy and existing programs should work.  If it is not possible to get the latest MDOS version running "as is" without modification, then there are going to be many programs that will not run and I would question how many people would actually jump on board.

 

As far as a cartridge port, myself, I am not particularly keen on a cartridge port.  Are there really any cartridges that users wish they could run on their Geneve?  Outside of potentially DragonSlayer and perhaps Matt's Finalgrom cart for the TIPI, those would be the only two cartridges.  From what I read, it took the developer several years to reach the point where it was ready for release.  Is there really any other ports that would be in cartridge form only that would be used on the Geneve 2020?

 

Just trying to be realistic here.

 

Beery

 

 

[+FarmerPotato]

On 12/14/2019 at 1:42 PM, BeeryMiller said:

As far as XOP's and interrupts, please keep in mind programmers have approached multiple routes for some of their programming.  Some programs using the XOP's to do/get video data and keyboard data, while others go straight to the ports and bypass the XOP's all together.  Some even mix things up depending upon the needs or what worked for them at the time.  I'm not sure how your "Supervisor mode" would interact in these situations.

 

Your first task should be to get an unmodified latest version of MDOS running.  If you accomplish that, then everything else is bread and gravy and existing programs should work.  If it is not possible to get the latest MDOS version running "as is" without modification, then there are going to be many programs that will not run and I would question how many people would actually jump on board.

Hi Beery,

I really value your feedback. You are probably the #1 user to consider.

Let me assure you that when I dream up new features, I'm still going to keep things compatible. I think breaking even one program that people expect to run, is too much. I'm probably going to fail that promise, but strive to offer a replacement. (like making a utility redundant with a built-in.)

A key concept in operating system design is the Hardware Abstraction Layer, or HAL. HAL makes the hardware details invisible to the program that is running, making it think it's on the system it was written for.  I'm working toward a HAL that MDOS will see as its native environment, with the goal of binary compatibility. As you said, being able to run the latest MDOS binary as a test.

Getting the HAL right could mean two things. 

One way, the machine is custom-built to run MDOS exactly, and not use any features that are distinctive to the 99000 architecture. MDOS runs in supervisor mode, with a new boot EPROM to set things up. There might be a bit that puts it in a New Mode. (Like Geneve/GPL cru bit that changes the memory map for all the device ports in the Geneve 9640 gate array.) 

The other way is, the machine uses the 99000 to its full potential, and a Supervisor carefully sets things up (along with the FPGA) to run MDOS in a compatibility layer. This is analogous to going from from DOS to Windows XP. All the old applications are preserved, but "DOS" is no longer in full control. Direct hardware access can be intercepted, permission granted, and bytes forwarded. This is the interrupt and XOP model I described recently. It's actually easier to fix compatibility problems under this model. 

I'm interested in building a machine with the full potential of the 3rd generation 99000. I think that is much more exciting.  It means using supervisor/user modes, allowing for multitasking between MDOS and something else. (For instance, another MDOS image, a debugger outside MDOS, a standalone GPL, and so much more.)

The Geneve 9640 provides a HAL to the GPL environment by mapping devices into the addresses that GPL expects, and so on.

My Supervisor would put MDOS into a 2MB address space of its own, with bank registers and the memory-mapped ports where MDOS expects. These things are mapped in the FPGA to the actual things. The FPGA would also recognize the Geneve/GPL mode bit change, and flip the port addresses within that 2MB space. That's a HAL: MDOS gets just what it expects.

Keyboard Simulation

All the keyboard inputs I've imagined, will be translated into one AT keyboard stream, and delivered to the port where MDOS expects them. Simultaneously, that will be mapped into a 8x8 keyscan matrix, that the 4A originally used. (That could be provided to GPL mode to make old KSCAN and all direct-keyboard access compatible again.) MDOS will just see a thing that looks like its gate array and key input port. This is done in the FPGA, which receives the keyboard stream from the 9995 coprocessor and queues it up. That's a HAL, and will make things "just work". As a bonus, the keyboard input could also be from the high-speed serial port, which might allow remote access.

 

At the same time, I'd like to make GPL more compatible than even the Geneve 9640 offered. To do that, more HAL under GPL mode. Like adding back the 8x8 keyboard matrix.  Under GPL mode, the 9901 could look exactly like it did in the 4A, keyboard lines and all. I want to re-fix the issues with VDP registers reserved bits being trashed (some GPL programs were patched to fix this.). This would be done in the FPGA, which forwards all the VDP ports. 

(There might be some logical contradictions with restoring the 9901 in GPL. I don't know if any programs were written for GPL that also peeked at the Geneve-specific CRU bits? Like, checking the bit for whether a keycode was ready, or left mouse button. Also, the TI ROMs are already patched for KSCAN. So maybe the "more compatible GPL" will have to wait for a "New standalone GPL" program. I imagine a New GPL that just takes the original ROMs.) 

Breaking Mouse Functions

A big difference between V9938 and V9958 is that the mouse/lightpen is gone from the VDP. So there must be a new mouse interface, from the PS/2 mouse through the 9995 I/O coprocessor and the FPGA. 

The logical way to work with this is to write a new XOP for GetMouse* functions, residing in the Supervisor EPROM. (As a refresher: in the 99000, Supervisor gets first look at any interrupt, XOP or LIMI call, and can handle them itself, or forward them on to the User task.) The Supervisor can take the XOPs for GetMouse* , do the job itself, then return to the caller--no changes to the MDOS binary. 

Another piece of this puzzle is in the VDP interrupt handler. The code in MDOS VX-INTS does sprite motion, sound duration, and mouse updating. It polls the VDP mouse registers for X and Y and middle/right buttons, and tests the CRU bit for the left button. 

The logical way to work around this is to put a new interrupt handler in the Supervisor. It would rewrite the handler entirely, ignoring the code in MDOS.  Another way is to branch to the original handler, let it do its job (including reading the empty VDP mouse registers), followed by the Supervisor tacking on the real mouse updates. The end effect has to be that the TRUEX and TRUEY, button bits, and other variables get updated the way MDOS expects.

(Aside: the interrupt handler, and the MDOS API, has dreadful sound support.)

I think the mouse behavior is going to work. UNLESS there are some applications that try to read the VDP mouse registers themselves (or the left mouse button CRU bit). 

I'm not really excited about providing a HAL for deleted VDP functions. It means having the FPGA intercept reads of some VDP registers to mimic the old behavior. It's possible? but I'm not thrilled to have to do it, unless the effort provides something new and great.

 

Other V9958 differences besides mouse

V9958 drops composite video (does anyone want an encoder added back in?) It has a horizontal scrolling register (yay!). No lightpen/mouse interface. It has a version detect bit. It adds a crazy new YJK color mode with 15-bit RGB colors. Superimpose and external sync are more robust. Most important, V9958 is easy to get for $8. Otherwise it is close to the V9938. (Aside: V9978 and V9990 are nonexistent and unobtainium.)

Summary

I'm aiming to use the full potential of the 99000 architecture while not breaking any Geneve software. As Beery said, running an unmodified MDOS binary should be the test it has to meet. 

[+FarmerPotato]

On 12/14/2019 at 1:42 PM, BeeryMiller said:

As far as a cartridge port, myself, I am not particularly keen on a cartridge port.  Are there really any cartridges that users wish they could run on their Geneve?  Outside of potentially DragonSlayer and perhaps Matt's Finalgrom cart for the TIPI, those would be the only two cartridges.  From what I read, it took the developer several years to reach the point where it was ready for release.  Is there really any other ports that would be in cartridge form only that would be used on the Geneve 2020?

 

I just like the idea of real hardware to plug in. I think you said you preferred a machine in a PC case, so the module port would be irrelevant. I think the slot would be beneficial for people to load up their FinalGROM to move to a 4A, especially after developing.

 

I'll make the final board fit inside a PC case form factor with a ports panel, but I'm building a standalone console for myself.
 

Also on the topic of "real hardware". I'm whimsically making the memory 30-pin SIMM modules (which are still being sold new.) Anyone can plug in 2, 8, or 32MB (in pairs). Maybe 8MB will be standard.

 

[+Ksarul]

V9990 chips aren't "quite" unobtainium. I do have four or five of them, IIRC. That's just not enough of them to make production boards with.

[+FarmerPotato]

On 12/16/2019 at 8:24 PM, Ksarul said:

V9990 chips aren't "quite" unobtainium. I do have four or five of them, IIRC. That's just not enough of them to make production boards with.

 

Geez... you do find everything!

 

They were used some years ago to make a run of new carts for MSX2 Turbo R.

 

I would love to overlay the V9990 on the V9958 - they have compatible superimpose mode (I think, if they are set to the same resolution.) The V9990 contains only the new modes planned for MSX3. Because V9978 was cancelled, and its V9958 core was pulled (licensing reasons) leaving the V9990 product. (Or so I have read on the forums.)  I think that if you put the two chips together, you get something great.

 

The V9990 has some crazy video modes, but reportedly 20x speed at block moves (a weak point of the V9938.) It's  not backwards-compatible with V9938.

 

See this V9990 review and this article

 

List of known V9990 games on MSX Turbo R.

 

EDIT:

 

Well, dang, look at all these suppliers claiming to have new V9990 stock. I might just get a quote.

Caveat: working with that 128-pin package terrifies me.

 

And the answer is,

V9990 is available from one seller at qty 50 @ $24

Another for qty 10 @ $10.

Another for qty 50 @ $24.

As for the dual-port VRAM required, I found some on eBay for $1.50 each

 

I'm going to put V9990 on my list for 2021. The idea will be a V9958 superimposed on a V9990 because the V9990 has no text mode and no compatibility. Transparent pixels on the 9958 would show through to the V9990 video mode. I already made a schematic and board laid out for twin 9958 with a high-speed RGB switch, so...

 

"Video cards" will be swappable on their connector, and on my prototype schematic/early layout (last week), there are  2 VDP select lines for 2 identical 9958 "cards". I'm only making one 9958 now though. I'm using  IDE connectors (2x20) in the prototype backplane for an 8-bit bus, device select, port#, interrupts, etc. This bus prototype is set up for "cards" with up to 4 Yamaha chips (2 MSX-video, 2 MSX-audio) and an F18A carrier, all pluggable independently. 

 

So I could make, separate video card options at different times:

 

• V9958 only
• F18A carrier (please don't plug in a 9918A) on second monitor
• V9958 + V9958 on one or two monitors
• V9958 + V9990 on one monitor
•  

 

I'm really happy that an upgrade to the 9958 is possible. As one MSX owner wrote in 1995, upon getting the Graphics 9000 upgrade for their MSX Turbo R, "We're no longer stuck in 1985."

 

 

 

[Nick99]

YES! V9958+V9990 on one monitor will absolutely be my choice!

I see potential, and with some practice to get programming skills ?... Well I hope to contribute with the things I like to do most, music and perhaps graphics too.

 

 

[+FarmerPotato]

Prototype Status

 

I was able to spend some holidays layout out the prototype PCBs. The prototype is for proving the features one
by one. On Saturday, I showed some work in progress to the members of Central Texas Retro Computer Society, and got some feedback. 

 

 

 

The CPU board uses connectors to 4 separate boards with FPGA, memory, VDP, and sound. The prototype will have 640K of RAM and paging. 
It will be able to emulate the GPL or Geneve memory map, but as a prototype I expect it to have bugs It's going to boot to a FORTH prompt,
where the hardware test code will be a joy to write.

 

The two large chips are TMS99105 and TMS9901.

 

The connector on the right goes to a EEPROM and Static RAM board. The two chips next to it are '573 address latches.

 

On the left are two TTL serial connectors, one for the console and one for a MIDI board. There are two real 9902 UARTs. TTL levels only.

 

The bottom three connectors go to the BlackICE FPGA, which then connects to the VDP, Sound, and DAC modules. They are buffered by LVC245A which translate 5V to 3.3V.

 

The keyboard/mouse PS/2 connector is not shown in 3D, but it's at the lower left corner. I had to model that one from the physical item. 

 

A 6-pin Molex cable is to carry +5V, RESET, and interrupt pins over to the VDP and sound boards.

 

Power barrel jack requires a regulated +5V supply.

[+mizapf]

Maybe we should start thinking about a proper name. "Geneve 2020" is not a cool enough.

 

Once your system is working, I will be able and happy to add it to MAME.

[+FarmerPotato]

8 minutes ago, mizapf said:

Maybe we should start thinking about a proper name. "Geneve 2020" is not a cool enough.

 

Once your system is working, I will be able and happy to add it to MAME.

 

I know, there is a secret name. Geneve2020 is just what I said back at the start.

 

Trivia: each prototype board is named after Steven Universe characters. The CPU module is Sapphire. (you can see it in the URL)

 

I had a thought about a MAME emulation *before* hardware, to make software development easier. Does MAME have a TMS99105/99110 though? And the Verilog in the FPGA would have to be translated. (Maybe it would help if I used mostly  standard cells like LS138, LS573, etc? I dunno, my only look into MAME was for the speech chips and OPL4.)

 

 

[+mizapf]

Currently, there is no code for the tms99000 family, but once there was, before the Great Rewrite. I still have that code, which needs to be adapted to the current architecture. It is not so easy to create a good emulation when you have no real device to test against; thus, I'd gratefully take your system as a reference.

[+FarmerPotato]

Physical layout of the prototype modules. The connector locations are wonky, but it's just for testing.

 

 

 

FM will be one of Yamaha OPNA (Sega Genesis), OPL3 or OPL4 (Sound Blaster) type, FM sound chips. All have digital output, mixed in the FPGA. The FPGA has SN76489 cores, and can play notes on FM instead.

 

 

[+FarmerPotato]

I hoped to have a February progress report on 2/20/2020, but what I have is:

 

1. The V99958 board has been sent to OSH Park. ETA Mar 4.

 

2. Instead of sending the CPU board to OSH Park, I am laying it out again as 3 separate boards, with a nice clean bus. CPU has ports for FPGA bridge and 2 cards. Separate Memory and CRU cards. Memory module is interchangeable between a simple 128K BIOS, or a later bank-switched module with higher chip-count. 

 

Where does the VDP, Sound, and 2-32MB DRAM go? Those all connect to the FPGA board.

 

I considered making it a 4 inch cube with backplane and 6 cards, but I'm sticking with lays-flat-on-my-workbench. This *is* just a prototype. Working prototypes will be open-sourced (as will the entire project).

 

3. Sound card (FM) will have at least two YMF262 OPL3, and SN76489.

 

4. Negotiating for some IP. 

 

5. Delayed by puppies. 6 out of 7 puppies are adopted out. Remaining puppy ran off with a 4A transformer. Whew. 

 

Code name dictionary

 

Sapphire - CPU module

Garnet - Sound (FM) module

Pearl - VDP module

Steven - FPGA module

Lion - Memory module

Connie - CRU module + RS322

 

 

[+FarmerPotato]

This is the first real hardware for Geneve2020.

 

The V9958 VDP board is partly done. Next I will be breadboarding the analog portion - RGB driver and composite encoder - that piggybacks on top. It will drive a VGA monitor supporting 15kHz. (Acer G276HL Kbix)

 

Time to begin testing the memory interface and/or debugging. The test environment is swapFORTH on the BlackIceII FPGA board. 

 

 

[+FarmerPotato]

The other parts of the video board:

 

 

All the video signals go on one 2x8 header, so the ports can be arranged in other ways. This build has VGA, a TI-99/4A composite DIN-5, and S-Video. SCART and RCA jacks are doable.

 

 

 

[+FarmerPotato]

I've arrived at this design for a motherboard and system modules. I moved to this design because my main board was becoming a mess.

 

This is flexible enough to support many experiments. It may stay on as a system in its own right, but each proven technology can move into a single Geneve board.

 

The backplane carries all of the CPU signals and is a 16-bit bus. All connectors are keyed 40-pin. To make a working system, you would plug in:

 

1. CRU / IO interrupt processor (9901). Serial, keyboard, mouse ports.
2. BIOS ROM/RAM.
3. Main RAM with memory mapper.
4. Open - maybe a sound/video card

 

The fourth slot connector can be soldered vertical or horizontal (for easy debugging.)

 

The bottom ports are an interface to a 3.3V FPGA card. One pin is a signal that the FPGA is taking over the memory bus.  The idea is that the FPGA will manage a very large DRAM and do the bank mapping, while also providing the overall memory map in GPL or MDOS mode, including access to 8-bit devices.

 

An 8-bit bus from the FPGA goes to sound, speech, and video cards (my 9958 card). And any other 8-bit legacy devices, which it can map at the right addresses for GPL or MDOS.

 

However, this design is useful for experiments that don't involve an FPGA or Geneve compatibility. You could run any of Stuart Conner's 99105 ROMs as the BIOS (in fact I'll test with his FORTH in the ROM.) I might adapt the sound and video card to plug into the 16-bit bus. The fourth slot could also host a slot expander to 4 more slots.

 

This is the first prototype of the Geneve2020. I think it will appeal as a new system on its own, like the RC2014. Its purpose now is to test modules, that will later become integrated on one Geneve board.

That is a KiCad 3D view, with copper exposed. I’m not ordering the PCB just yet.
 

Remaining parts of V9958 boards are arriving though. 

[GDMike]

Is it going to do solid-state hard drive, and wireless connectivity? 

[+FarmerPotato]

7 minutes ago, GDMike said:

Is it going to do solid-state hard drive, and wireless connectivity? 

There will be 1 or 2 SD card slots. 

Any networking will be through a TiPi (which is indifferent to wired or wireless). That idea is a long way out. But JediMatt42 already has a standard so I'm sticking with it.

Putting a wireless stack (ESP8266) or even a USB controller inside seems unfair - either chip has far more power than anything inside.  Sure the Pi does too

 

I haven't thought about how it gets to any Pbox cards like an HFDC where all your software exists. Or how it might live in the pbox. But there is one 8-bit bus for starters.

 

[+FarmerPotato]

On 3/7/2020 at 1:18 AM, FarmerPotato said:

The other parts of the video board:

 

 

All the video signals go on one 2x8 header, so the ports can be arranged in other ways. This build has VGA, a TI-99/4A composite DIN-5, and S-Video. SCART and RCA jacks are doable.

I was building this today. When I discovered that the VGA footprint doesn't work. I made a mistake and selected the one that says 1.97mm spacing instead of the one that says 2.54mm spacing. No wonder I had trouble routing the trace to a pin in the middle. My 2 kinds of connectors are 2.54 between rows.

 

I should have noticed this on the 3D viewer. I didn't notice it on the paper-punch copy I made, but know that I look, it's obvious on the holes on paper.

 

I'm going to have to spin up a new VGA breakout board to test this thing.

 

 

Also, comically, I didn't plan for 220uF caps to be bigger than 47 uF caps. I can still solder them on, but it looks like a shrub.

 

[Tornadoboy]

Thought I'd give this thread a kick and see if anything new is going on? COVID-19 is complicating a lot of things to say the least, lockdowns and sickness aside I imagine there are major supply chain disruptions to electronics and PCB fab. 

[+FarmerPotato]

2 hours ago, Tornadoboy said:

Thought I'd give this thread a kick and see if anything new is going on? COVID-19 is complicating a lot of things to say the least, lockdowns and sickness aside I imagine there are major supply chain disruptions to electronics and PCB fab. 

Thanks for the query - I am always putting off the status update, hoping to get one more thing working...

 

I am still putting a lot of effort into Geneve2020. The design is still partly realized in hardware, partly in KiCAD, and definitely just a prototype. There are a lot of decisions to make for the final shape.  The V9958 card is under test. I continue to design the CPU and other modules around a backplane. Which is "done" in Kicad, except, I keep tinkering with the design and not sending it to get PCBs.

 

Getting stuff is not a problem so far - OSHPark delivers PCBs, Shenzhen sellers and Mouser are doing business. I have most of what I need already.

 

Here is a photo of the V9958 card under test:

 

 

So that's my work environment. The wire harness goes to the VirtualBench (I love that tool). You can see the V9958 card with breadboard fixes. It is attached to the BlackIce-II FPGA board, which is now running SwapFORTH so I can write video test programs in FORTH.

 

Here is a photo of how I got organized, finally:

 

And here is a photo of my 4A setup:

 

 

VDP Status

 

I made fixes to the V9958 on a breadboard. I added transistors to  Vsync, Hsync, Csync, inverted Hsync, and those look great now. I don't understand why the other designs  for V9958 use those honking 220 uF capacitors coupling the RGB-sync outputs.

 

So the Samsung 910MP monitor syncs on VGA, I think, but I haven't written any data to the V9958 yet, so the picture is black. The Samsung doesn't show the menu either, so I can't verify the sync frequency (for instance, using F18A it tells me 31.5kHz). I have not tried RGB (SCART). My Acer G276H is not recognizing the sync - boo, it's supposed to do 15kHz. I have a lot more RGB monitors (Apple) that I can try out, but getting a 4:3 aspect VGA output is imperative.

 

FPGA Status

 

The north 3 ports of BlackIce are where it will interface to the 16-bit backplane, essentially the raw 99105 signals. The east 3 ports (with all the test leads) are the peripheral 8-bit bus for video and sound. (The backplane contains the CPU, CRU, serial ports, and BIOS memory on plug-in boards.)

 

I haven't written any of the Verilog where the 99105 backplane is bridged to the 8-bit bus.

 

I have swapFORTH running on the FPGA. This is ideal for writing 9958 test code.

 

I haven't figured out yet if there will be a unified backplane for 8 and 16 bit buses, with an FPGA card bridging them. The FPGA needs to bridge the 16-bit bus to the 8-bit bus. It does all the memory mapping, such as paging and connecting the VDP ports to the right 16-bit addresses in GPL or MDOS mode. If/when there is a P-Box bridge (a real must-have), it too will come through the FPGA bridge.

 

 

So that's where I am. I have been at home since Mar 13, rarely going out. And then not getting out of my car. Strangely, I am spending even more hours working from home, with less fun time.

 

[+FarmerPotato]

Still working on V9958 board bringup: digital side. Status: I found bugs in hardware.

 

MeCrisp Ice version of FORTH is running on the FPGA. It is great. I can add FORTH vocabulary at compile time. I plan to keep this as part of the BIOS.

 

I wrote the VDP initialization and read/write primitives in FORTH. I verified all the digital outputs from the FPGA.

 

This was painful because I didn't use the standard pin order on the PMOD ports:

 

The PMOD standard for the 2x4 data pin connector is: 1x4 row on top is the high nybble, 1x4 row on bottom is the low nybble.

 

I went left-right down the rows, so my PCB could have all the traces on the top layer, in order. The PCB is
quite beautiful that way and all 8 data port traces snake around into a '245 transceiver.

 

I had to rewrite the Verilog to scramble and unscramble the bits. This took hours to get it right. Alas, this is the third FPGA project where I have designed myself into this mess. (In another, I wired the 4A data bus to the closest pins and unscrambled it in the FPGA.)

 

The pin headers interface to the 8-bit peripheral cards is this:
 

A0-A7 data bus to/from VDP

B0 VDPWAIT from VDP
B1 NC -   
B2 MODE0  register select
B3 MODE1  register select
B4 CSW*   write strobe
B5 CSR*   read strobe
B6 SS0    device select
B7 SS1    device select

C0-C7     OPL3 digital audio to the FPGA, BIOS TX and RX

Continuing with board bring up--the memory test has failed. The 9958 is getting the right data, and CSW*. But no CSR*.

 

I finally discovered that I had this '138 with the address inputs wired backwards. So no CSR*.

 

Here's my '138 chip:

LS138 3-to-8 Decoder

0   SS1   VCC
    CSR   Y0 illegal but harmless
    CSW   Y1 -> CSR1* read cycle
0   G1A*  Y2 -> CSW1* write cycle
0   G2A*  Y3 idle state, both high
SS0 G1    Y4 
    Y7    Y5 -> CSR2*
    GND   Y6 -> CSW2*

Mistake. G1 should be tied high. SS1 should be a low-enable and SS0 should be an address bit. This makes Y5,Y6 the CSR2,CSW2 for the second VDP chip (yep, dual screens or superimpose or F18A ....)

Chip select bits from the FPGA, 8-bit peripheral bus
  

SS1 SS0
  0   0  VDP2
  0   1  VDP1   (got this wrong but ok)
  1   0  OPL3-1
  1   1  OPL3-2

 

Back at the '138 decoder:

  
SS1 CSR CSW
 0   0   0   Y0    illegal
 0   0   1   Y1    read cycle
 0   1   0   Y2    write cycle
 0   1   1   Y3    idle

 
This '138 arrangement solves the lack of a chip select pin on the 9958 - the CSR and CSW signals are gated by
my SS0,SS1 chip selects. 

 

Alas, I wired the address bits backwards. You can see that the write cycle is symmetric, so, that works. But the read cycle
is broken in a way that I will just have to code around. Yuck. Until I rev the board.

 

Another mistake is that the 5V WAIT output goes to a 3V3 input on the FPGA. Oops.

 

Here's a nice screenshot of a VSBW - VSBR cycle! The CSR signal never reaches the 9958 though, so the memory test fails.

 

<insert here>

 

Thus goes the VDP board bring-up.  I will see if I can have Amanda solder some wire to correct the address pins, or, mangle the software to work with it...

I have CSR0, CSR1 primitives to hide this in.

 

<Hidden - FORTH code for interested parties>

 

[+FarmerPotato]

Promised screenshot of a VSBW - VSBR cycle

 

Signals

 

CDATA is the data bus: 1 byte hex (the 00h means hex).

 

M0 and M1 are the mode bits or port select.

 

SS1 and SS0 are the chip selects - here set to VDP1.

 

Each CSW* low pulse sends a byte of data to the V9958. The CSR* pulse reads a byte of data (well it would, except bugs)

 

The SS with hex is all the above bits, shown as a hex byte.

 

Time axis

 

Starting around the trigger (T), you can see the VDP address on CDATA as 00h, 40h. This is >4000 or write to address 0. It happens during M0=1 and M1=0 (like VDPWA >8C02 on the 4A.)

 

After the address is set up, change M0=0 (think VDPWD or >8C00 on the 4A)

Then FFh is sent to the data port with a CSW* pulse.

 

Next, the address is set up again, this time to >0000 for a read (no >4 bit.)

 

Then the port goes back to M0=0 and M1=0 (Think >8800 on the 4A), and CSR* is pulsed. Which should result in the VDP output of FFh on CDATA but ... hardware bugs. Fail.

 

The analog signals like CSYNC are null, because I pulled off the analog board. Had  to do that in order to reach more digital signals.

WAIT is all screwy. I'm not sure why. Its unfortunately at LS 5V level logic, while the FPGA input pin is 3V3. Oops.

 

The little spikes are just glitches in my logic analyzer wires. They do not show up when I use the analog scope probe. Though you can see the little knots on the red trace. Red is CSW* except the 10X switch got flipped so it's squshed.

 

[+FarmerPotato]

For the curious, the promised FORTH source code for VDP primitives:

 

https://gitlab.com/FarmerPotato/geneve2020/-/blob/master/src/vdp/vdp.fs

 

Feel free to explore the rest of the repository. Geneve2020 will always be open source.

 

These words run on the J1A FORTH processor inside the FPGA. This is a very useful feature of the fpga, so that some implementation can be done in a high-level language. It is kind of cheating to have a 25 MHz coprocessor, but, it will be invisible.

 

In the future, these VDP words will run under the 99105 FORTH, too. The io primitives for J1A (io@, io!) will be coded as CRU read/write, which the fpga will translate to the J1A io registers. So VDP access from BIOS will be through CRU. But don't worry, that's only for the BIOS. MDOS or GPL still access VDP in the usual way.

 

The BIOS will be written in 9900 FORTH - analogous to OpenFirmware from PowerPC days. It will be in EPROM. The machine will always boot into BIOS, initialize some things, then go directly into MDOS (loaded from the CF card). Unless you push a key to get just the BIOS (FORTH) prompt.

 

Also, upon a system crash, aka Blue Screen of Death, or debug LOAD interrupt, you can drop to the FORTH prompt.

 

(On a PowerPC Mac, Cmd-Option-O-F was the magic keypress to boot into the FORTH prompt, where you configure or query various things, before booting MacOS).

So, there will be TWO hidden FORTH environments in Geneve2020. One that is the BIOS that does the boot process, and another J1A FORTH processor inside the FPGA. The one in the FPGA will do magic things, like a super debugger.

 

 

[+FarmerPotato]

P-Boxes

 

I've been thinking about how to connect a P-box to Geneve2020.

 

The need for this is to preserve the usefulness of your existing hardware. Disk drives, speech card, RAMdisk, TiPi, you name it.

 

I don't think Geneve2020 is a good fit for the inside of the P-box--it would take up at least 5 inches of width if I did that. So I think a new flex-cable card is the way to do it. You could move a P-box backplane into a PC tower along with the Geneve2020.

 

Flex Card

 

The new flex card would drive the 5 additional address lines ADA...ADE.  It would have a nice round cable, like the more fashionable Ultra ATA or SCSI cables.

Like this: http://www.cablesonline.com/3cnmaltocnma1.html

 

50 pin SCSI cable should be enough--there are 40 active signals, plus you need a bunch of ground wires. You can choose your length.

 

The 16 to 8-bit multiplexer would be on the Geneve2020 end.. I don't think there is any use for a 16-bit bus reaching the Pbox. Right now, it seems to me that the Geneve2020 end is a 4x4" plug in card, while the P-box end is a traditional card size (less is not mechanically stable?)

 

Of course, going P-box would be optional.

 

How to combine old and new

 

1. Some software peripherals will exist onboard Geneve2020. Obviously, memory expansion is onboard, because 2MB is cheap. Speech is another--TMS5220C onboard (slightly incompatible).

 

2. You would write in your config file which pages you want to open up as windows into the physical P-Box 2MB space. For instance, enable Pbox RAM expansion pages (but why?) or speech  or TiPi.

3. You would also configure which CRU ranges go to the physical P-box. If it's kept onboard, it reaches a new or re-created peripheral (say onboard RS232). If it's off-board, the CRU cycle goes out to the Pbox.  For instance:

 

>1000 either a Master DSR for MDOS onboard, or a mixture, or even a window to the Personality card (WDS1) if you have that.

>1100 either an emulated DSK1 (think CF7A+ format volumes on SD card) and HDSx, or an external controller. 

>1300 either the onboard serial ports, or passed through to the Pbox.

>1x00 always-on access to SD card devices: SD1, SD2 or such. Regardless of whether they are mapped onto DSK1,DSK2 etc.

 

Enabling original DSR ROMs is a goal here, especially (only?) in GPL mode.

 

Enabling the MDOS Master DSR to see the real hardware is another goal.

 

I have a simple scheme for creating all this magic. The FPGA has a signal, I am calling it RDBENA for fun. When RDBENA is asserted onto the 16-bit bus, the FPGA owns the current cycle, suppressing all other cards. When it is not asserted, other devices on the 16-bit bus can interpret it.  Put simply, the FPGA recognizes the start of a CPU memory cycle into address space that it "owns" and asserts RDBENA.

 

This is how I make the actual BIOS EPROM/RAM chips appear in the whole 64K at startup, while the FPGA can suppress those chips while in MDOS or GPL modes. (Even so, the 99105 can assert its own PS bit to seize direct control of the 64K space and suppress the FPGA. Interrupts do this. LDS and LDD instructions facilitate moving memory between these spaces.)

 

Similarly, the CRU address >1300 could be "taken over" from the physical serial port. It could point through a UART into the hidden super-debugger FORTH prompt, all controlled from within your favorite terminal software. Or it could pass through a window onto the physical P-Box.

 

If the FPGA sees that a particular memory access is inside a configured "window" to the P-Box, it simply lets it through, not asserting RDBENA. It's then up to a peripheral card (the flex card interface) to handle it.

 

Sharing

Getting data from physical floppies or HFDC in the Pbox. How would this work? You would want to be able to copy from physical devices to SD and vice versa. One solution would be to read files from a physical WDS1 or DSK1, and write to SD1, or vice versa. With emulated DSK not active.

 

Another is to run two copies of MDOS at once, with one of them set up to access the P-Box, while the other MDOS image is running without Pbox devices. Some magic moves data between them, or they just communicate through files...

 

More Magic

 

In fact, you could configure any pages as windows into physical space, RAM or not. For instance, to choose what pages are RAM to MDOS. And whether the GPL cartridge page(s) goes to an image loaded in RAM, or to the physical cartridge port!

 

Pages are just a map to translate # 00-FF to a wider register in the FPGA. A read or write to any address is translated to the thing this register points to. Nothing has to be hard-wired. The 2MB MDOS space is already "sandboxed" virtually somewhere inside the 32MB maximum RAM, with its page numbers loaded with a code pointing to physical RAM. MDOS never knows about this -- only the BIOS knows this when it sets up an MDOS to boot (and it could boot more than one into memory simultaneously.)

 

Why Physical P-Box Cards?

 

I don't want to build a physical disk controller! SD card is what I'm focusing on.

 

I don't know all the use cases! I'm not going to close everything off and say "if you want to have X, it must now be emulated in new code plus magic." This was Myarc's error, not to facilitate standard DSRs. Meaning all your devices had to be re-created in MDOS master DSR, until ROMPAGE came along. I would prefer that all the real cards work in GPL mode at least. (DSRs are obviously written for the GPL environment.)  I don't even want to try to know about and plan for everything.

 

Hey, I don't see why you would want to use your physical memory expansion card, when onboard RAM is 32MB. But knock yourself out. A RAMdisk? Why not, if you have all your favorite software already loaded there? A print spooler? RS232? Maybe sometimes. TiPi? For sure. (Though there will be a way to integrate TiPi to Geneve2020 -- its too important.) SAMS? Well... memory is cheap... (emulating SAMS will be a cinch.) AVPC? Why not? SID master? Doh!  What others?

 

Maybe the physical cards are always just more reliable than a software re-creation! (Provided that sensitivity to CPU speed is solved. Geneve2020 will have several smart speed modes.)

 

Why not use the original flex cable? Because there are 5 new address lines to put in, plus a SGCPU bit. 

 

Just don't plug in your physical Geneve at the same time. (What? That's a crazy idea.. too crazy.. hmm...)

 

Issues

 

Math for those following along:

 

an 8-bit number covers values 00-FF , which are page numbers used in MDOS

a 16-bit address covers 64K or 2^16

a 13-bit address covers 8K or 2^13 which is the single page size in MDOS

The LS612 memory mapper has at least 8 registers that store at least 8 bits.

A 16-bit address is split into upper 3 bits (bank) and 13 lower bits. The 3 bit bank# is replaced with 8 bits from the memory mapper register.

The resulting 21-bit address is the full address in 2MB space or 2^21

Adding 5 address lines to the P-box gives the 2MB address space that the physical Geneve used.

 

 

 

1. How does a 16-bit memory address from the 99105 translate to a 21-bit P-box 2MB space address?

 

Here's the problem:

 

The flex card interface doesn't own the memory mapper--the FPGA does.

 

The LS612 type memory mapper is inside the FPGA--thats how the FPGA translates 16-bit addresses together with page numbers 00-FF into 2MB Geneve addresses (or memory-mapped devices).  Inside the FPGA, there is a Geneve 2MB memory map, actually located somewhere in the 32MB main memory. (there is a 2MB base address that is added for each memory cycle... it might just be 0)

 

 

So how can the FPGA tell the flex card that a) this is definitely a P-box cycle and b) here are the upper 8 bits of the address (the page number)?

 

1A. Half of the time it is probably in GPL mode, so the 16-bit address is actually all the P-box needs. 

1B. From MDOS mode, the flex card needs that 8-bit page number!

 

Solutions:

 

1C. First, add a backplane line "External Bus Access Enable" (EXBAE) from the FPGA.

1D. This is where it hurts... 8 address bits out of the FPGA is a pretty big chunk of the pin budget (it will break the budget.) Does it have to be a direct 8 address lines?

 

Can it be sent serially? Any delay in transmitting this to the flex card, will ruin the memory cycle timing. I've done the math for the 4A and it barely works in a 333ns cycle; 99105 address window is 83ns.  Granted, the FPGA/flex card combo is generating wait states at this point, which gain the time. Still, a LS164 shift register (serial in, 8 bit out) on the flex card would need CLK, D, RST - 3 wires. I've spent a hundred hours debugging that scheme already--using the 4A side port.  An 8 bit direct line is much cleaner.

 

I guess 4 lines is a conceivable budget to pull this off. Though 9 would be better. I'm still not sure if more signals are needed. Does the FPGA generate the wait states and 16-to-8 multiplexing? Does the flex card do that 16-to-8 with an onboard state machine (just like the 4A). This would all be much easier if it were integrated into the FPGA, and save a lot of chips. Then the flex card would be just 244 and 245 drivers, plus 8 bit latch (bringing the data bus up to 16 bits.) The FPGA would generate A15, WE and DBIN, and wait states for the CPU.  That's 12 lines for parallel... 7 lines if a serial LS164 scheme is used.

 

I'm going to think about this some more.

 

2. I also don't understand which Pbox devices might generate extra wait states.

==========

 

Hmm, all this becomes simple if I conceive of it as an 8-bit peripheral next to the VDP... that reuses existing pins! Yeah, the flex card gets one port for address (like VDPWA), another for each data byte (like VDPWD)...

 

Port 0 Write 3 bytes of address, using CSW pulse. (VDPWA takes 2 bytes of address)

Port 1 

Port 2 Read/Write data, even byte

Port 3 Read/Write data, odd byte

VDPWAIT - this is where the P-box READY line goes.

 

The additional signal, EXBAE, is a function of the flex card being selected and read/written. No additional pin required.

 

So... that's the flex card interface, with 0 additional FPGA pins used up. Yeah!

 

I've been calling this the "8-bit bus" or "slow bus" for a while now. I realize it also contains the P-Box solution.

 

0 extra pins required!!!

 

To Read before Write?

 

An option here is: whether the Geneve2020 emulates 9995 or 9900 read-before-write bus activity on the 8-bit bus.

 

Memory cycles for 9900 or 99105 16-bit data bus:

 

Read 16 bits.  (2 reads)

Modify 8 bits

Write 16 bits. (2 writes)

 

Memory cycles for 9995 8-bit data bus:

 

Read 8 bits  (if say we are doing Add Byte)

Write 8 bits

The FPGA is going to do what the 99105 tells it to do. So, there will be a read-before-write. Unlike the Geneve 9640.

 

P-box cards for the 4A work fine with read-before-write. Are there any cards for the Geneve that don't like read-before-write?  I hope I am not overlooking something...

 

Slow Bus Device Select

I need to finally convert the unused pin, to the SS2 select bit that I expected. The 8-bit device list is now:

SS2,SS1,SS0

000. VDP1
001. VDP2
010. FM1
011. FM2
100. Flex Card memory
101. Flex Card CRU
110. Speech
111. Cartridge port

The 8-bit bus control register is thus:

SS1.  SS0.  CSR.  CSW.  A1.  A0.  SS2.  WAIT.

I will  rearrange this in the next VDP PCB and further peripherals (not on PCB yet), and add SS2 to the 138 decoder. (see last post for raw details of  VDP access.)

 

 

The 8-bit data register is still:

D0 D1 D2 D3 D4 D5 D6 D7

 

 

 

 

 

[Nick99]

I see that you´re prepared for all sorts of wishes and demands people can have. ?

As much as I like the magic that I read, I will be happy with a stand alone computer with all the memory, graphics, speech, sound and SD card read/write.

Yes, a TIPI is nice to be able to connect for networking.

Anyway, a really great work you have done!