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

[Tursi]

I'll tell you this, I'll never code a USB stack again.  USB is awful.

 

I don't know why we keep saying PS/2 is hard to find.. I see 372 vendors for PS/2 ports on Mouser... keyboards are easy to come by. PS/2 is dedicated and faster to boot.

 

PEB connection would be important to a console PCB replacement, IMO.

 

[Shift838]

On 8/2/2019 at 8:18 PM, Tursi said:

I'll tell you this, I'll never code a USB stack again.  USB is awful.

 

I don't know why we keep saying PS/2 is hard to find.. I see 372 vendors for PS/2 ports on Mouser... keyboards are easy to come by. PS/2 is dedicated and faster to boot.

 

PEB connection would be important to a console PCB replacement, IMO.

 

I agree with Tursi on this.  PS/2 is easy to find and cheap.  I can buy PS/2 mice and keyboards almost anywhere still.  Hell, i just bought a cheap PS/2 keyboard from my local Micro Center for $8.00

 

 

[Omega-TI]

2 hours ago, Shift838 said:

I agree with Tursi on this.  PS/2 is easy to find and cheap.  I can buy PS/2 mice and keyboards almost anywhere still.  Hell, i just bought a cheap PS/2 keyboard from my local Micro Center for $8.00

 

 

I'd sure like to find a NIB WIRELESS & AFFORDABLE PS/2 keyboard!  Do you have a link for a NIB one?

[Shift838]

12 minutes ago, --- Ω --- said:

I'd sure like to find a NIB WIRELESS & AFFORDABLE PS/2 keyboard!  Do you have a link for a NIB one?

Wireless PS/2 ?  no..  i've actually never seen one of those or even heard of one.  i'm talking wired PS/2.

[Shift838]

i could probably make a module using arduino along with a nRF24L01 to make it wireless, but not sure I would want to do that.

[+arcadeshopper]

I have some older ps2 Logitech wireless

Sent from my LM-G820 using Tapatalk

[+chue]

6 minutes ago, Shift838 said:

i could probably make a module using arduino along with a nRF24L01 to make it wireless, but not sure I would want to do that.

Someone already did the keyboard part, no mouse though:

 

 

[Shift838]

1 minute ago, chue said:

Someone already did the keyboard part:

 

 

This project i have seen before and it sends the RF signals down the USB line.  So the USB side picks them up.  I bet a receiver if coded correctly could receive the signal and input it to the real PS/2 port.  But again, I ask myself what would the real use case be besides proving it could be done.  i think it would cost more in time than i would be willing to spend on it.

[Omega-TI]

1 hour ago, Shift838 said:

Wireless PS/2 ?  no..  i've actually never seen one of those or even heard of one.  i'm talking wired PS/2.

Yeah, already have a PS/2 keyboard on my current TI, I like it, it works great, and I'm quite happy with it.  However, when the F18A MKII comes out, I'm not going to want to mess with my current console, I want to get a new console built up with all the latest and greatest contemporary parts as my "final TI system", so that would be the F18A MKII and a Jedimatt42 USB keyboard adapter (so I can plug in a wireless keyboard).  The mouse is not an issue, because with TIPI, I already have a wireless mouse on the system that works.    Now if a modern Geneve had a F18A MKII for video output and wireless ...

 

What can I say, it's a bucket list want.

 

 

[Shift838]

5 minutes ago, --- Ω --- said:

Yeah, already have a PS/2 keyboard on my current TI, I like it, it works great, and I'm quite happy with it.  However, when the F18A MKII comes out, I'm not going to want to mess with my current console, I want to get a new console built up with all the latest and greatest contemporary parts as my "final TI system", so that would be the F18A MKII and a Jedimatt42 USB keyboard adapter (so I can plug in a wireless keyboard).  The mouse is not an issue, because with TIPI, I already have a wireless mouse on the system that works.   

 

What can I say, it's a bucket list want.

 

 

Wireless USB keyboards are the easiest to find and work great with JediMatt's USBKeys.  

[Tursi]

5 hours ago, --- Ω --- said:

I'd sure like to find a NIB WIRELESS & AFFORDABLE PS/2 keyboard!  Do you have a link for a NIB one?

I had a fairly nice wireless HP keyboard back in the day, but I hated the concept of the battery dying in my input device, and put it aside the first or second time it happened. I probably still have it somewhere.

 

I did a quick hunt of Amazon, and the first thing noted is that the filters don't work. But it does seem like /wireless/ PS/2 is a pretty rare thing. I had better luck at NewEgg with a Logitech, but the price isn't worth it. So I guess for cheap wireless, yeah, go USB.

 

[+FarmerPotato]

Another caffeine and cookie fueled night.

 

In this revision you can see:

• The CPU is a TMS99105. I got a very reasonable quote for these in quantity (Ksarul helped). Performance might be 3x TMS9995.
• The FPGA is central, with buses going in 4 directions to CPU, video, RAM, and back ports.
• The board is modular. The pieces are mainboard, video, back ports, and side ports.
• The board is still designed to fit neatly into a beige 4A case.
• Two PS/2 ports and two SD card slots are on the side where the expansion hole was.
• One USB port, although I'm not hopeful about it. If it comes to be, it will support a hub.
• Now TIPI fits inside your computer.
• Still no PEB connector.

Goal is still 100% software compatible with MDOS and TIMODE. (After supporting PS/2 and SDcard.)

 

FPGA would perform all the functions of the gate array and PAL in the Geneve, including generating wait states to slow things to 4A speed.

With a 4A case, you would make one cut in the back plastic to let the ports out. Also, a nice new plastic panel is easy for me to laser-cut.

 

I may create a vertical PCB for all the ports, in which case there will be room for more ports.

 

If you prefer your own case, the parts can be separated, with short header cables to the ports. The video card could be swappable with a card holding an F18A or two. 

 

[Nick99]

This computer is what I have been waiting for a loooooong time! 

I like the Geneve, but I miss the sound capability that this will give, and of course not to have a harddrive has not been effective.

 

Exciting project, thanks for sharing the progress!

[+InsaneMultitasker]

Two thoughts come to mind:

An MK2 socket would be nice as an option or alternate to the 9938/58.  Most people stick with the  TI/F18a graphics modes and 80 column text anyway.

Add a few extra CRU bits or modify existing use to emulate some TI features, such as a 512K ROM cart mode and/or unhinge the >6000 space so that any 8k page could be mapped there.  Currently, the Geneve forces the use of only two pages at >6000.  Simulating a 512K cart is do-able but you have to copy the contents of the banked page and hack the program's memory map code to bank pages  (this does work...  but 4096 moves is slow if there is a lot of mapping).

 

 

[+FarmerPotato]

10 hours ago, InsaneMultitasker said:

Two thoughts come to mind:

An MK2 socket would be nice as an option or alternate to the 9938/58.  Most people stick with the  TI/F18a graphics modes and 80 column text anyway.

Add a few extra CRU bits or modify existing use to emulate some TI features, such as a 512K ROM cart mode and/or unhinge the >6000 space so that any 8k page could be mapped there.  Currently, the Geneve forces the use of only two pages at >6000.  Simulating a 512K cart is do-able but you have to copy the contents of the banked page and hack the program's memory map code to bank pages  (this does work...  but 4096 moves is slow if there is a lot of mapping).

 

 

Good suggestions!  I hope you are interested in this project--your expertise would be invaluable.

I will have a lot of questions for you about MDOS behavior (if and when) I get to programming!

Like how are keypresses presented... is there a byte in the memory map?

 

Memory Mapper

 

My memory mapper in FPGA uses 4K pages in 16 registers. I've only tested this for side port 32K RAM so far. It's a SAMS memory mapper in the DSR space. It can put DSRs in the usual way at >4000 and cartridge pages at >6000. The actual bank registers can be wider, but look like 8 bit registers to most software.

Anyway, emulating more bank schemes would be just software changes. It might even be worth adding another 2MB RAM, just for cartridge emulation. I assumed TIMODE would see the extra RAM as SAMS pages.

 

Banking could change in exciting ways with the 99105's separate supervisor 64k code and data spaces.   In case I didn't mention, all RAM is on the 16 bit bus, a terrific advantage over the TMS9995.

 

I think being able to plug in an actual, physical cartridge is cooler than emulation. All the computer has to do is route the usual signals in TIMODE onto the cartridge port!

 

CRU

 

I am not sure how the 9901 CRU will look. On one hand, I think of matching the 4A, so if TIMODE programs read the bits directly, they will find the keyboard and joystick lines they expect.

 

On the other hand, MDOS uses CRU bits as IO and uses them for gate array connections (we saw 2 in the PAL thread) and that would conflict. 

 

On the third hand, that would be easy to understand modification to MDOS.

 

TIMODE perfect keyboard compatibility means using 15 IOs of the FPGA, in a sort of merge with the 9901, the 4A keyboard, the PS/2 keyboard, and joysticks.

I checked the IO pin budget. It's 93 pins available on the FPGA, and the plus 15 keyboard lines busts the budget.

 

I don't want to emulate the whole 9901 because the point is to use real hardware. (I'm also not sure about clocking the 9901 and 9902 at 6Mhz from the 99105.)

 

CRU is a puzzle so far.
 

Still yet another wacky CRU idea is to emulate the IO, and put a real CRU at a different address base, to give the programmer lots of external IO pins. Or just add another 9901 for that!

 

[+InsaneMultitasker]

A good starting point would be to review the wiki - Michael has documented good info there.  Another source would be the Geneve MAME emulation source and of course, source from MDOS and the Geneve boot EPROM.  

 

How much you want to forklift into FPGA and similar 'new' hardware is of course up to you.  Maintaining compatibility with the Geneve and/or TI while adding new methods of operation, well, that can get tricky.  I'm in no position to contribute much beyond simple conversation and brainstorming but I am certainly interested in where you (will) take this idea. 

 

 

[Tursi]

What about putting an actual cartridge port in? It may require a quick loader to bring it into the memory space, but it was the one thing the Geneve really lacked, no? If you have room in the FPGA, it'd be nice to keep that.

 

 

[+FarmerPotato]

4 hours ago, Tursi said:

What about putting an actual cartridge port in? It may require a quick loader to bring it into the memory space, but it was the one thing the Geneve really lacked, no? If you have room in the FPGA, it'd be nice to keep that.

 

 

I'm all for that. There's room in the FPGA logic (until I stress it with that USB host controller...) . You could run software from the cartridge.. or there could be a software thing to slurp it all into RAM like you said. So I put the physical cartridge port on the 3D PCB.  Kicad just didn't have 3d models for card edge connectors.

 

The FPGA is the traffic intersection. It has a 16 bit data bus to the CPU and a 16 bit data bus to RAM. It will have an 8-bit "slow" bus to memory mapped devices.

Here's where that helps:

 

If the CPU accesses the slow bus through a memory mapped address, like VDPWA or the real cartridge port at >6000 in TIMODE, the FPGA generates wait states on read, but  latches the address/data for writes and returns control. The next write to the slow bus must block until the previous write completes (READY high.)  This technique appears on some MSX computers for VDP and sound writes.

 

Single writes to VDP or speech would seem to go at full speed. I *might* even add a write FIFO so several bytes can get set up.

 

Since the CPU is still only 6 MHz, but the RAM is at least 50 MHz, the CPU doesn't use all the RAM cycles. So the FPGA can be doing other things in and out of RAM, saving precious onboard bits.  One of those things is emulating Speech ROM TMS6100.

 

Because writing to the speech port is extremely slow, an alternative would be to allocate a RAM page for speech, and just tell the chip to speak an address. The usual tricks to feed speech data slowly become "store it in RAM and kick it off." The FPGA will service the TMS5220's requests as needed.

 

 

 

[+FarmerPotato]

7 hours ago, InsaneMultitasker said:

How much you want to forklift into FPGA and similar 'new' hardware is of course up to you.  Maintaining compatibility with the Geneve and/or TI while adding new methods of operation, well, that can get tricky.  I'm in no position to contribute much beyond simple conversation and brainstorming but I am certainly interested in where you (will) take this idea. 

 

I want to put in as much real hardware, and emulate some things. The FPGA will be IO limited before it runs out of logic gates.

 

Here's how the pin usage is allocated so far:

 

16 address/data from TMS99105 cpu.
12 control lines from cpu: ALATCH, MEM, WE/IOCLK, RD, R/W, APP, HOLD, READY, 4xBST
0  interrupt control: connected to 9901. INTREQ, IC0, IC1, IC2, IC3
0  RESET, NMI
19 address lines to RAM.    Add 1 for another 2MB, put a 138 on CE. 
4  memory control lines OE, WE, CE0, CE1. 
16 data lines to RAM
8  slow bus for memory mapped devices: vdp, speech, sound, cart data port
1  slow bus READY, mux
3  Device select on the SPI bus and READY mux. VDP, Speech, Sound(?), cart data, 2 sd cards
3  SPI mosi, miso, sclk. 
4  vdp control: mode0,1. csr, csw
2  midi
4  i2s
4  ps/2
7  speech rom (4 addr/data, 2 control, romclk)
==
103

I have 99 io pins free. Perhaps the slow bus 8 will become a latch on the SPI bus.
 

[+9640News]

4 hours ago, FarmerPotato said:

I'm all for that. There's room in the FPGA logic (until I stress it with that USB host controller...) . You could run software from the cartridge.. or there could be a software thing to slurp it all into RAM like you said. So I put the physical cartridge port on the 3D PCB.  Kicad just didn't have 3d models for card edge connectors.

 

Only issue with "slurp it all into RAM" is what about carts like Dragon's Lair?  Can't slurp there.

Beery

[+FarmerPotato]

2 hours ago, BeeryMiller said:

Only issue with "slurp it all into RAM" is what about carts like Dragon's Lair?  Can't slurp there.

Beery

Nope, not going to try. A real cartridge port is for innovative cartridges like that.

If the cartridge port behaves like a real one, you could plug in FinalGROM or Dragon's Lair.

 

"slurp into RAM" would be for well-known bank schemes. Like any number of full 8K pages and an address latch. Really just a size update on what the Geneve did to support cartridges that were known in its day.

 

 

 

 

[+FarmerPotato]

I looked at Thierry Nouspikel's page about the Speech Synthesizer TMS5220.

http://www.unige.ch/medecine/nouspikel/ti99/speech.htm

 

I learned some really interesting facts.

 

The TMS5220 outputs digital samples before they go to the DAC. This feature is not connected on the 4A. It would be cool to capture the digital stream. My sound is all digital (emulated, or sampled actual 76489A) (this is tested). So it would be convenient to mix digital rather than analog. 

 

Doing the Speech ROMs in RAM will require the 6 line ROM interface in the FPGA. It will allow any existing LPC codes to be stored in RAM banks (provided they were coded for the same chip version). The SNUG(?) speech card added a lot of vocabulary from other TI products. Existing code would continue to work through the slow SPCHWD address and so on, but mapping the ROM into >4000 or somewhere would allow you to load new phrases or search the the dictionary directly on a 16 bit bus. 

 

BTW, Unicorrn Electronics has a pile of TMS6100 speech ROMs. I bought one to see what's in it.

[+9640News]

On 8/4/2019 at 3:53 PM, FarmerPotato said:

Good suggestions!  I hope you are interested in this project--your expertise would be invaluable.

I will have a lot of questions for you about MDOS behavior (if and when) I get to programming!

Like how are keypresses presented... is there a byte in the memory map?

 

The Geneve has multiple maps for the keys depending upon what key mode one is in.  Various keypresses are tested via CRU bits as I recall, to distinguish ALT-F1 versus CTRL-F1, or F1.

 

Your best resource to understanding this is to look at one of two pieces of code.  Either get the MDOS source and look at the L5/L6 libraries (they are combined) where L5 is keyboard and L6 is video.  Another resource lifted from MDOS source is the original MyTerm source code which I think can be found on whtech.

 

Bruce Hellstrom's BHDMV program was a good tool I used to give Ralph Nabet when he was originally developing the Geneve emulation in MESS  the feedback on what keys a real Geneve should be feeding back versus the hardware.

 

Beery

 

[+FarmerPotato]

My design uses surface mount devices. I'm comfortable with that. But others are not up to that.

 

I decided that to make this kit-able, I can move all the SMD components onto one central board. This will be called "The Cube".

 

This way, all the difficult soldering could be done by an expert (say, in batches in a reflow oven). The Cube is 60x60mm and has regular 0.1" spaced pins around the edges. Anyone could assemble the rest of the computer with a soldering iron. Also, this frees up a big space underneath for routing!

 

The Cube has the FPGA, 3.3V translation logic, address latches, the stereo DAC, EEPROM, and LDOs. The pin spacing  ranges from 0.5mm (FPGA) to 1.27mm (TI logic chips) (thru-hole parts are 2.54mm.)

 

Each side of the Cube faces a group of chips:

 

• East:  99105 CPU 16-bit bus (pin 1)
• North: IO ports (mouse, keyboard, MIDI, SD, EEPROM, Stereo DAC)
• West:  "Slow" 8-bit bus: VDP, speech, cartridge, PEB connector.
• South: RAM 16-bit bus (2, 4, or 8 MB)

 

This turns out to be a really good match between the available IO pins and devices.

 

The Slow bus is like the 16 to 8 bit circuit in the 4A. Where the 9900 takes one cycle to write 16 bits, the 4A slowly does this in 6 cycles.

 

The Slow bus will  buffer one 16-bit write operation with no wait states. The CPU can continue with something else while the Slow bus finishes the write. Obviously it doesn't help with reads. If there is another read or write to Slow bus before that completes, then wait states are generated until the Slow bus is free. This is an idea used in some MSX machines. It means the CPU can be doing something else while waiting on VDP, Speech, or physical GROM to complete the write. A CRU bit will read out whether the slow bus is free (great if your code can take advantage of it.)

 

For one example, GROM access takes 10 microseconds or 600 cycles of the 99105! Yes I'm allowing for physical GROM on the cartridge port. You can even put the console GROMs there if you like.

 

[+FarmerPotato]

On 8/2/2019 at 8:18 PM, Tursi said:

I'll tell you this, I'll never code a USB stack again.  USB is awful.

 

I don't know why we keep saying PS/2 is hard to find.. I see 372 vendors for PS/2 ports on Mouser... keyboards are easy to come by. PS/2 is dedicated and faster to boot.

 

PEB connection would be important to a console PCB replacement, IMO.

 

I will never try to code a USB stack. But you learned a lot, didn’t you?

 

I think I have found a USB solution. The FTDI 311D is a $4 chip intended to connect peripherals to Android phones or tablets. It hosts 2 devices that can be regular or full speed USB. 

 

Weirdly, the FT311D acts as a host with the tablet being the device (Android Open Accessory Mode.) This is not a problem though.

 

Bottom line is, for $4 this chip can host a keyboard and mouse, and connect to the SPI bus (into the FPGA) for queuing up keyboard or mouse bytes.

 

EDIT: I got FT311D mixed up with VNC2. The VNC2 provides 2 USB ports and costs $10.90. FT311D has one port and might be too specific to Android.
 

I still want to do PS/2 as well. 

Edited August 7, 2019 by FarmerPotato