Jump to content
FarmerPotato

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

Recommended Posts

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

 

 

  • Like 1

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites
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.

 

  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites
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."

 

 

 

Share this post


Link to post
Share on other sites

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.

 

 

Share this post


Link to post
Share on other sites


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. 

 

 

SapphirePCB.thumb.png.d1102b41cfbf0c6c7d24353a493289e2.png

 

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.

  • Like 2

Share this post


Link to post
Share on other sites

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.

  • Thanks 1

Share this post


Link to post
Share on other sites
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.)

 

 

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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

 

 

ProtoBlock.PNG.7005d77259f737705a7ec62fc6841b23.PNG

 

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.

 

 

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...