Jump to content
IGNORED

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


FarmerPotato

Recommended Posts

Yep, I'll be watching like a hawk how this develops. :D

 

Ok my thoughts, questions, prayers, mindless babblings...

 

Probably stupid questions:

- How backwards compatible will it be with the standard 99/4a? I've never seen a Geneve and have no idea how compatible it was, personally my interests center around the original 4a, particularly Basic, X-Basic and cartridge software. I get the impression it's going to be but I thought I'd ask. 

- Will it be speed adjustable? In other words, can you speed up or slow down the performance to accommodate software that either runs best at a normal 4a speed or would benefit from significant speed increases?

- What will the default boot be like? Will one have a chance to pick TI basic? Would it be possible to also have XB or one of the improved XB versions, editor assembler or all three be selections?

- Will I be able to install the F18 VGA chip in it? I have the older version I bought a while back but haven't installed yet. 

- Any ballpark guesses on the price? Over/under $200?

 

Other thoughts:

- LOVE the idea of it being modular, that'll make any possible future hardware corrections/improvements much easier to implement without having to start completely over. Perhaps what seems impractical now someone will later find a clever way to make it work after all or discover a cheaper substitute for an otherwise expensive part? Etc. I have nothing specific in mind, I'm just a guy who loves keeping as many options open as possible! 

- I like the idea of this being a stand alone console, the PE is kind of a beast and at least for me desk space is at a premium, not to mention most of what I'd need a PE for is going to be built into this anyway. It is a great idea to keep the cartridge and expansion port though regardless, again, flexibility.

Personally I want to set it up on my computer desk and have it loaded up with pretty much every program in existence, so I'll never have to touch it other than the keyboard and power switch. Want to play Tunnels of Doom? Go to the right menu and run it. Want to play Cavern Quest in XB? Go to the right menu and run, etc, and not have to fumble with a gazillion cassettes, disks and cartridges.  

Edited by Tornadoboy
  • Like 1
Link to comment
Share on other sites

6 hours ago, Tornadoboy said:

Yep, I'll be watching like a hawk how this develops. :D

 

Ok my thoughts, questions, prayers, mindless babblings...

 

Probably stupid questions:

- How backwards compatible will it be with the standard 99/4a? I've never seen a Geneve and have no idea how compatible it was, personally my interests center around the original 4a, particularly Basic, X-Basic and cartridge software. I get the impression it's going to be but I thought I'd ask. 

- Will it be speed adjustable? In other words, can you speed up or slow down the performance to accommodate software that either runs best at a normal 4a speed or would benefit from significant speed increases?

- What will the default boot be like? Will one have a chance to pick TI basic? Would it be possible to also have XB or one of the improved XB versions, editor assembler or all three be selections?

- Will I be able to install the F18 VGA chip in it? I have the older version I bought a while back but haven't installed yet. 

- Any ballpark guesses on the price? Over/under $200?

 

Other thoughts:

- LOVE the idea of it being modular, that'll make any possible future hardware corrections/improvements much easier to implement without having to start completely over. Perhaps what seems impractical now someone will later find a clever way to make it work after all or discover a cheaper substitute for an otherwise expensive part? Etc. I have nothing specific in mind, I'm just a guy who loves keeping as many options open as possible! 

- I like the idea of this being a stand alone console, the PE is kind of a beast and at least for me desk space is at a premium, not to mention most of what I'd need a PE for is going to be built into this anyway. It is a great idea to keep the cartridge and expansion port though regardless, again, flexibility.

Personally I want to set it up on my computer desk and have it loaded up with pretty much every program in existence, so I'll never have to touch it other than the keyboard and power switch. Want to play Tunnels of Doom? Go to the right menu and run it. Want to play Cavern Quest in XB? Go to the right menu and run, etc, and not have to fumble with a gazillion cassettes, disks and cartridges.  

 
 Hi Tornadoboy,
 
 Not stupid questions.. I'm looking for feedback on what features people want more.

It will boot to MDOS.. unless somebody writes a FORTH boot (heh heh). You can make an autoexec file that says GPL and this will open the 99/4A title screen. All the cartridge options you mention are probably doable in software.
 
 My goal is 100% compatible, even more compatible with 99/4A software than the Geneve was. The Geneve made your peripherals obsolete unless MDOS included a driver. I would hope to support all the existing Pbox cards in GPL mode by getting that 100% compatibility.  There will be more problems to solve. 


Getting the speed to match the 99/4A for time-sensitive (games) software is tricky. However, because of the way the 3rd gen cpu TMS99105 operates, together with the FPGA, it will be possible to make a lookup table to tune every instruction or memory access to match the 4A. The Geneve just had 5 speeds.
 
 
 I drew the video card to have a simple connector. All the signals the F18A needs (and more) are on that connector, so it would be easy to make a board to hold the F18A. (really, a beginner could do it with Kicad.)


 In fact, the F18A would be the best option. I want to finish 9958 support, but, compatible monitors are hard to find. I do have a hare-brained scheme for upscaling the 9958 to HDMI but it is raving bonkers.

 

No idea on price. I just got a quote on the CPU less than a week ago, which seemed like a green light.
 
 I'm glad you like the standalone aspect, however, someone is going to want their disk drives or Horizon RAMdisk to work, so I'm reserving space for a PBox interface (new card, not the flex cable.) But you're right that most of what you need will be in the console. If SD card storage is good enough, you won't need any other drives.
 
 I want to hear ideas on how to leave expansion possibilities open. A TIPI connector is one. I think TheBF would prefer to see a new 16-bit bus. Bringing back Hexbus might not be a bad idea.
 
 I'm concerned with how to add Internet still. I hope to talk to jedimatt42 at some point about how the TIPI could work here. Another option is an ESP8266. However, people are writing software for TIPI and that's terrific.
 

  • Like 3
Link to comment
Share on other sites


Craziest idea of all

 

First the non-crazy:

 

So I have a working hardware for an 8-bit bus multiplexer. It's called IceTea. It plugs into the 4A side port, interfaces the 4A to an FPGA board, while minimizing the number of FPGA pins to 15.

 

I drew the reverse of IceTea to be the Geneve2020 PBox/cartridge interface. Instead of responding as a device, it controls the bus. 
This will be part of the Slow Bus: an 8-bit data path to VDP, Speech, cartridge, side port. Separate from the CPU's and RAM 16-bit data bus.


This can drive the Pbox. In MDOS mode, the interface card (Flex replacement) would transmit the expected Geneve 9640 signalling to the Pbox. That uses 3 extra address lines and a 2nd Gen CPU signal, DMA transfers, good stuff. That would be ok for GPL mode too, staying the way MDOS does things. But MDOS limits you to drivers built-in to MDOS. Since there is no Geneve 9640 actually IN the Pbox, I thought why not write a true 4A compatibility mode when GPL is running? Then you could use any card you happen to have. Maybe even P-code!

 

(Definitions: MDOS is the native OS of the Geneve 9640. GPL is the familiar 4A environment you launch from MDOS. It reconfigures the memory to look like a 4A but the DSR page only points at MDOS drivers, not your original cards' ROMs.)

 

OK, that's the non crazy down-to-earth stuff.

 

Here's where the crazy starts:

 

What if you could have both a Geneve 2020 and a Geneve 9640 meeting up in the same PBox?

 

They both have a DMA interface. This is where a peripheral requests that the CPU go into a holding state while the peripheral uses the memory bus. When the CPU grants the request, the peripheral uses the memory bus for a while, then returns control. On the 990 this is useful for disk controllers to read or write sectors of data from RAM without going through the CPU.

 

So, imagine the Geneve 2020 and 9640 are hooked up to your PBox. You run a program on the 9640 and save some files to the disk there. Then you request to open the same file on the 2020. It requests access to the PBox, waits for the 9640 to grant it, then runs the disk drive for a little while to get the file.

 

Here's another scenario. You compile MDOS on the super-fast Geneve2020. Then you copy the resulting SYSTEM/SYS to your hard disk in the Pbox. While you are doing that, the Geneve 9640 is in a hold state. When you finish the copy, the Geneve 9640 wakes up and you reboot it with the new MDOS. Then you find out that you trashed the hard disk. C'est la vie. I told you this was crazy stuff!
 

  • Like 4
Link to comment
Share on other sites


Now for crazy bonkers idea #2 for today:

 

The 9938 and 9958 VDPs output 15kHz RGB video. This is unfortunate because 15kHz monitors are increasingly rare. You need 25MHz or better VGA output to sync up with common monitors.

 

You could use an upscaler and hope for the best, but these are expensive. Upscaler kits are out there for arcade RGB video, but even those are scarce.
Chips that do this conversion are a really hard problem too.

 

So, the 9958 has this feature called a color bus that outputs the pixel data while the video RGB signal is being emitted.

 

I thought of taking the H and V sync signals and the color bus into the FPGA. There would be a frame buffer there to store all the pixels. Then, a VGA driver would output the corresponding image!

 

This would not work for twin 9958s in superimpose mode. At least, the V9958 manual indicates that the color bus is inactive when superimposing. I don't see why the FPGA couldn't reimplement superimpose mode from two synchronized color buses, though.

 

Another issue is that the color bus outputs color numbers, not the final RGB values. If you have set the palette registers, the FPGA needs to know about that.

 

Fortunately it acts as the traffic director to the VDP anyway, so, it can remember all the writes to the palette registers.

 

Another issue is memory. There is not room inside the FPGA for a whole frame buffer. It would need to share RAM.

 

In the real world, this problem is solved by Karl Guttag's dual-port VRAM, which is a video chip DRAM with an extra port that outputs 1 row of pixels when requested. The chip that makes the video signals will pull a row of pixels out. It sends that to the screen, by which time the next row is loaded in, and so on. The CPU never notices.

 

To do video, the FPGA would need to steal external RAM cycles.  The external RAM can spit back data at 50MBits/s. So the time to read back 256 8-bit pixels is 128*20=2560 ns. The 99105 memory cycle is 183 ns, so clearly this is going to clobber CPU performance when it occurs. However, a lot of 20ns memory cycles can be hidden in between CPU memory accesses!  A line needs to be loaded up every 31 us (microseconds), which is 186 CPU cycles. Among those cycles, we need to hide 128 reads from RAM. It's likely this doesn't disturb the CPU at all.

 

http://tinyvga.com/vga-timing/640x480@60Hz

 

This is way more than I intended to tackle. Just plug in a F18A when it's ready! But I thought exploring the idea was interesting.

 

 

  • Like 3
Link to comment
Share on other sites

1 hour ago, FarmerPotato said:


Now for crazy bonkers idea #2 for today:

 

The 9938 and 9958 VDPs output 15kHz RGB video. This is unfortunate because 15kHz monitors are increasingly rare. You need 25MHz or better VGA output to sync up with common monitors.

 

I can see that being handy if someone wanted to use the Geneve 2020 as a coin operated arcade game platform! :D 

I've had fantasies of hooking up a 4a in a arcade cabinet with Microsurgeon and having it play on an Exidy Max-A-Flex like coin timer, I've always wanted to play Microsurgeon with Robotron-like controls! Personally I wouldn't waste my Geneve 2020 for that particular game, but for others who want to make games from scratch it would just be a matter of the monitor, connecting the controls to the joysticks and the coin switches to keys of the keyboard, so if it's not too much of a headache you might want to have it still be able to output that type of RGB if one wants it to. 

Edited by Tornadoboy
Link to comment
Share on other sites

A few thoughts as I inhale my lunch...

 

TI compatibility for the Geneve often boils down to software incompatibility (direct keyboard scanning and cartridge banking beyond the type used for XB carts, wrongly set video regs, etc) and the low level peripheral support.  Fortunately for the latter, TIMODE and rompage allow for accessing the cards just like they are in a TI system with some exceptions, such as GROM conflicts or DSR speed-related issues.

 

You mention RAMdisks - what about sticking a few nonvolatile RAM chips on the board at a CRU or two to simulate?   there are 1- 2- and 4- MB chips available last time Ksarul and I were looking into them.

 

I can't really see myself putting this into a TI case -- one luxury for me, as a geneve user, is getting beyond the firehose and console. 

 

A standalone Geneve 2020 in a new case would be nice.  I have a Skull Canyon that sits innocently on my desk; maybe all that's needed is a new 'firehose' with USB or similar hardware to interface the Geneve2020 to the PEB bus?  Then the  Geneve2020 can be standalone but if you want to use a PEB, you use the new interface card.  Say goodbye to the side port.  

 

Rambling done.

 

 

  • Like 3
Link to comment
Share on other sites

1 hour ago, InsaneMultitasker said:

A few thoughts as I inhale my lunch...

 

TI compatibility for the Geneve often boils down to software incompatibility (direct keyboard scanning and cartridge banking beyond the type used for XB carts, wrongly set video regs, etc) and the low level peripheral support.  Fortunately for the latter, TIMODE and rompage allow for accessing the cards just like they are in a TI system with some exceptions, such as GROM conflicts or DSR speed-related issues.

 

You mention RAMdisks - what about sticking a few nonvolatile RAM chips on the board at a CRU or two to simulate?   there are 1- 2- and 4- MB chips available last time Ksarul and I were looking into them.

 

I can't really see myself putting this into a TI case -- one luxury for me, as a geneve user, is getting beyond the firehose and console. 

 

A standalone Geneve 2020 in a new case would be nice.  I have a Skull Canyon that sits innocently on my desk; maybe all that's needed is a new 'firehose' with USB or similar hardware to interface the Geneve2020 to the PEB bus?  Then the  Geneve2020 can be standalone but if you want to use a PEB, you use the new interface card.  Say goodbye to the side port.  

 

Rambling done.

 

 

I didn't know about rompage. Nice to know that problem was solved. 

I'm trying to solve the keyboard direct scanning. I might be out of IO pins.

Since actual hardware carts will plug in, any bank scheme will work there.. but supporting well-known bank schemes in software is doable.

 

 

RAMdisk - do you mean battery-backed RAM? I figured SD ought to be fast enough.

Or do you mean Flash chips? these are actually not as fast.

NVRAM: I looked up Cypress NVRAM. It costs $36 for 1 megabyte or $51 for 2 megabyte. 

 

For plain old SRAM, 2 megabytes costs $15.

I'm not messing with DDR or DRAM. On the other hand, DRAM costs $2 for 8 megabytes. There are free cores to manage this.. hmm. 

 

I'll just try to make the board small and modular. I am looking at a PBox port on the back, and an appropriate cable (round IDE with serial?)

 

 

  • Like 2
Link to comment
Share on other sites

I am suddenly fascinated with the possibility of being able to control the Speech chip via MIDI.

 

This could make the circuit benders really happy, and save some Speak N Spells from mutilation. Circuit benders mutilate  the original version of Speak n Spell to produce crazy noises. For use in mixing and DJing.

 

There would be something like CALL SAY over MIDI.. maybe raw LPC samples too.. And an allophone library linked to MIDI note numbers.

 

And then the modulation wheel could distort the clock and other parameters desired by the circuit benders. I'm not sure what all they do to torture the chip. I did play with a bent Speak n Spell at the store Switched On in Austin.

 

Lots of possibilities.

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

Adventures in 30-pin SIMM (Memory Modules)

 

I'm supposed to be working on FORTI-2, not this so-called Geneve 2020, but I did it anyway.

 

I made a carefully measured outline of the 4A motherboard and physical features, in CorelDraw. Then I imported it to KiCad as Edge Cuts.  Then I tore up the whole PCB and started over.


I focused on the 2MB static RAM area.  The data bus is 16 bits wide. A row of 4 61IS5128 (512Kx8) SRAMs provides two banks totalling 2MB. There is a 16 bit address latch so the address/data pins can be multiplexed. Those are the facts, the rest is theory. :)

 

I wasn't happy with how much space the static RAM took up on "the cube" where all the SMD chips were concentrated. I considered making RAM a plug-in board. Then it could also be upgradeable.

 

However, the SRAM chips max out at 512Kx8 (above which the pins get super tiny). Four SRAM chips + support chips take up 1x4 inches. Making a 4MB option would double that size.

 

So I took another look at DRAM chips. Then I found new sockets for old 30-pin SIMMs. I've considered all the tradeoffs, and favor 30-pin SIMMs. They are still available in pairs (4 x 1MB x 8) for $11, new.  Yes, they went out of style with the Mac SE, but they can cross the line from "obsolete" to "retro".

 

https://www.memoryx.com/generic-memory-30-pin-simm.html
https://www.memoryx.com/ayk.html

 

Phoenix still has the 30-pin twin right angle socket (which is ideal!) for $1.36
https://www.peconnectors.com/sockets-pga-cpu-and-memory/hws9229/


The tradeoffs include

  • slower access time (70ns is plenty good enough for 0-wait state CPU RAM on the TMS99105.)
  • It's more work to create and debug a DRAM controller before the machine can even work. 
  • 5V SIMM will need 5 support chips instead of 2.
  • However, it uses 3 fewer pins overall, and 32MB is a lot of potential!
  • Adds vertical height. Solved by using the 22 degree slant socket.
  • And you get the pleasure of physically snapping in your RAM modules.. start with the minimum, treat yourself to the upgrade later!

 

Q. How does 32MB work?  MDOS only addresses 256x8k pages (2MB) with 8 bit page numbers.

 

A. The bank registers get bigger, from 8 to 12-14 bits, covering all the 4K pages. There is still a 64K address per operand, though the 99105 allows for some long-distance 1MB addresses. 32MB exceeds the 24 bit (16MB) address space TI described when they allowed 12 bits of page register.  Or on the 99/8 with the weird 3-byte address kludge.  

 

Q. Why not both? Put in 1-2MB SRAM + SIMM expansion.

 

A. I'm trying to minimize the I/O pins required. Doing both makes the count go up.

A. We-ell. The IS61LV6416-10KLI is a minimal 64Kx16 SRAM that would share the support chips with SIMM (the 16-bit address latch) but add back 4 pins.

A. Hmm. It would be awesome to have both kinds of RAM maxed out. The memory map could be weird.. does the SRAM hide the first part of the DRAM? Or I can add 1 more bit to the memory mapper.

 

Q. Isn't doing both complicated?

 

A. Yes, its going to stress the I/O pin budget of the FPGA.

 

Q. What about other 1990s memory modules? 72-pin DIMM or SO-DIMM?

 

A. The modules are around, but the connectors have vanished. Not even on aliexpress. I think it's lucky that Phoenix still has the 30-pin socket.

 

  • Like 2
Link to comment
Share on other sites

1 hour ago, FarmerPotato said:


So I took another look at DRAM chips. Then I found new sockets for old 30-pin SIMMs. I've considered all the tradeoffs, and favor 30-pin SIMMs. They are still available in pairs (4 x 1MB x 8) for $11, new.  Yes, they went out of style with the Mac SE, but they can cross the line from "obsolete" to "retro".

I still have quite a few different types of simms from that era. Sounds like a plan.

Link to comment
Share on other sites


On the main board of a modern computer, you find devices connected with buses like SPI or I2C. These are all serial buses with 4 pins (2 for I2C). SD cards commonly use SPI. Audio devices use a I2S interconnect. 


I've implemented and tested the I2S bus for the CS4344 stereo chip, and SPI for the SD card. The USB chip speaks several protocols. I'll probably choose SPI for it. 


That brings me to...


The Parallel I/O Port. 


Because this is an assumed feature of the 4A, I won't drop it like NanoPEB did. 


On the 4A, PIO is the hacker's port because it can be used for any 10 signals in and out (see Vorticon's 2D CNC project) In the TI RS232 card it consists of dual 373 latches for the input and output direction plus a one-byte CRU register (see Thierry's RS232 schematic ). Rather than put all those chips in, I searched for I/O expander parts like my favorite LS595 (used in many Arduino projects.) 


I found this $1 TI 9534 part (I'm trying to select TI parts wherever possible.) http://www.ti.com/product/TCA9534A


It is a general purpose 8 bit IO port. Each pin can be configured as input or output. The 16-pin parallel port will need two of them because it has 8 i/o bits plus 4 extra lines.


It's going to work out nicely. "The Cube" FPGA block will control it using a 2 line I2C bus for up to 8 devices. 

 

The Cube is in charge of everything that happens in CPU memory space (RAM, bank registers, memory mapped devices like VDP) and can also respond to any CRU operation. (It's like NorthBridge in a PC.) So The Cube can present the programmer with the exact interface that is expected of the RS232 card at >1300 or >1500 in GPL mode. In particular, the parallel port is used by reading or writing >5000 when the RS232 DSR is paged in (you set bit 0 at the >1300 CRU base.)

 

But The Cube can easily provide additional CRU registers, for instance allowing the parallel port to be accessed as a serial or parallel CRU register in addition to the memory mapped >5000. Each pin of the parallel port will be programmable as an input OR an output.


*

 RS232 cru map
>1300   standard 4A register
    0 ROMSEL
    1 PIOOUT   direction of transmission: 
    2 PIO HANDSHAKEOUT/HANDSHAKEIN
    3 PIO SPAREOUT/SPAREIN
    4 
    5 CTS1
    6 CTS2
    7 LED
>1310   configure direction of I/O pins. 1s for output, 0 for input.
>1320   load or store I/O pins.
>1330   unused
>1340   RS232/1
>1380   RS232/2

Examples:


* 4A
LI R12,>1300
SBO  0           page in the RS232 card
SBO  1           set parallel port to output
LI   R1,>AA00
MOVB R1,@5000    write a byte out the PIO

* 99105
LI   R12,>1300
SBO  0           page in the RS232 card
SBO  1           set parallel port to output
LI   R1,>AA00
LI   R12,>1320   new register for PIO data avoids >5000
LDCR R1,8        write a byte out the PIO 

* 99105 with serial CRU and configurable I/O
LI   R12,>1310   direction register for PIO
LI   R1,>F0A0    want 4 pins of output and 4 pins of input; set outputs to A (1010)
LDCR R1,0        two-byte transfer: configure direction and set outputs for PIO 
LI   R12,>1320   values register of PIO
STCR R2,4        read just the inputs

* 99105 with parallel CRU and configurable I/O
* make some pins inputs, some pins outputs
* See 99105 Data Manual page 69 for explanation of the count field in parallel LDCR,STCR.
LI   R12,>9300   PIO register
LI   R1,>F0A0    want 4 pins of output and 4 pins of input; set outputs to A (1010)
LDCR R1,>A       parallel two-byte transfer: configure the pins AND set the outputs

INCT R12
LI   R1,>3000
LDCR R1,2        parallel byte transfer: change the outputs to 3 (0011)
STCR R2,2        read all 8 as inputs; output pins read back as 0.

* set all the pins of PMOD3 to PMOD7 to output direction, and set them to E5, except PMOD4.
LI   R12,>9304   PMOD1 address
LI   R1,>FFE5    make all pins into outputs, and set them to E5
LDCR R1,>B       parallel word transfer: auto-increment R12
LDCR R1,>B       parallel word transfer: auto-increment R12
LDCR R1,>B       parallel word transfer: auto-increment R12
LI   R2,>0000    for inputs
LDCR R2,>B       make PMOD4 all inputs.  auto-increment R12
LDCR R1,>B       parallel word transfer: auto-increment R12
LDCR R1,>B       parallel word transfer: auto-increment R12


CRU in general


The 99105 offers Parallel CRU operations. To use this, you add >8000 to the R12 base address. Whereas the 9900 transmits CRU bits serially (one at a time) on CRUIN/CRUOUT, the 99105 can put up to 16 bits on the data bus. Parallel LDCR and STCR execute in two cycles instead of up to 2N (where N is the number of bits).


Geneve 2020 will have one real TMS9901-40 CRU (4 megahertz verson) with the usual duties (trying to compatible with 4A and Geneve), and an unlimited number of virtual CRU devices in the FPGA. 


There will be two real 9902 chips for RS232, plus a virtual RS232/3 and RS232/4 at >1500 corresponding to some internal serial devices you might want to talk to. Because I will use real chips wherever it makes sense. 9902 clock speed will be switchable between 3 and 4 MHz.


Bonus 


Why stop at one parallel port?


Extra 9534 are no burden to interface. Up to 8 of them share the same I2C bus. I propose this add-on: an expander for the PIO, offering up to 6 more general purpose IO ports of 8 pins each. The 2 necessary lines could take over two of the PIO pins. Or next to the PIO port there will be a separate 2-pin connector exposing the I2C bus pins to the expander board. Hmm, if the 2 lines are on a new header, the PIO connector is just there to add stability. We'll call the 8 bit ports "PMODs" (a world of possibilities.)

 

Extended serial CRU map


>2300 alias of >1310 direction of PIO pins (aka PMOD0)
>2310 alias of >1320 read/write PIO pins
>2320 PMOD1 direction of PIO control lines (aka PMOD1)
>2330 PMOD1 read/write PIO control lines
>2340 PMOD2 direction
>2350 PMOD2 read/write values
>2360 PMOD3 direction
>2370 PMOD3 read/write values
>2380 PMOD4 direction
>2390 PMOD4 read/write values
>23A0 PMOD5 direction
>23B0 PMOD5 read/write values
>23C0 PMOD6 direction
>23D0 PMOD6 read/write values
>23E0 PMOD7 direction
>23F0 PMOD7 read/write values

Extended CRU parallel I/O map

>9300 PIO direction (PMOD0)
>9302 PIO values
>9304 PIO control lines direction (4 bits)
>9306 PIO control lines values    (4 bits)
>9308 PMOD2 direction
>930A PMOD2 read/write values
>930C PMOD3 direction
>930E PMOD3 read/write values
>9310 PMOD4 direction
>9312 PMOD4 read/write values
>9314 PMOD5 direction
>9316 PMOD5 read/write values
>9318 PMOD6 direction
>931A PMOD6 read/write values
>931C PMOD7 direction
>931E PMOD7 read/write values


Bonus Bonus

 

I already planned this feature, this seems like a good location to document it, so: The MSP430 executive has some unused ADC pins. These could be brought out on the same header next to the above I/O expander. Then you would have a hacker board with gobs of digital I/O and analog in.

 

Joyousness

 

Physical LEDs corresponding to the original PBox card LEDs. This could be an bar LED chip or some SMD LEDs. Or a connector for one of these: https://www.adafruit.com/product/1426

 

LTA-1000E_sml.jpg

  • Like 2
Link to comment
Share on other sites

Just a thought here, not knowing how it could be implemented or if it would screw everything else up.

 

Was thinking about a "turbo" mode.  I think the only way this could be implemented would be through a key press on the keyboard.  When in turbo, things run as fast as possible.  When not, normal speed.  Not sure if this could even be implemented.  Would probably require something like a Print Screen key and/or Scroll Lock combo to turn on/off.  

 

I can think of things like assembling programs where reads/writes could be done at the fast speed possible to save time.  With MESS prior to MAME, one could run in "turbo"  mode and one could assemble MDOS in its entirety in seconds versus minutes.

 

Just a thought as I don't have a clear picture on what kind of disk storage device(s) would be useable.

 

Beery

 

Link to comment
Share on other sites

55 minutes ago, BeeryMiller said:

Just a thought here, not knowing how it could be implemented or if it would screw everything else up.

 

Was thinking about a "turbo" mode.  I think the only way this could be implemented would be through a key press on the keyboard.  When in turbo, things run as fast as possible.  When not, normal speed.  Not sure if this could even be implemented.  Would probably require something like a Print Screen key and/or Scroll Lock combo to turn on/off.  

 

I can think of things like assembling programs where reads/writes could be done at the fast speed possible to save time.  With MESS prior to MAME, one could run in "turbo"  mode and one could assemble MDOS in its entirety in seconds versus minutes.

 

Just a thought as I don't have a clear picture on what kind of disk storage device(s) would be useable.

 

Beery

 


I have given some thought to Turbo/Slow speed and wait-state generation.

 

The 99105 is going to run "as fast as possible" with 16-bit bus memory and no wait states, unless slowed down. All disk access is from SD card (for now.) At least as fast as a NanoPEB or a TIPI.

 

My real concern is on the slowing down part!

 

GPLMODE (and also Geneve 9640 mode?) speed-matching will be done in the FPGA. First, the Geneve had a register to add a number of wait states to slow things down in general. I can improve on that. Since the 99105 advertises the bus state, it's possible to micro-analyze which instructions are executing, and insert wait states. The FPGA can then have a look-up table of how many wait states to insert for each instruction opcode, in order to match the performance of a 9900 or a 9995 on the 4A bus. Each memory access can incur a particular wait-state lookup for the type of memory: the 4A emulation needs 6 extra wait states (on the 3MHz clock) for the expansion RAM in GPLMODE for instance. This could be an extremely accurate speed emulation.

 

Turning the wait state generator off would result in "Turbo Mode" again.

 

Since keypresses on the USB or PS/2 keyboard are routed through a memory-mapped register inside the FPGA, it's possible for keys to have magic side effects, like setting the Speed option. So Ctrl-Shift-F1 or whatever would be an acceptable way to toggle speeds. (Other ideas: Generating NMI to force a screendump in GPLMODE.. literally PrintScreen could do what it's supposed to.)

 

So I was just thinking of the speed selector on the 99/8 startup menu (necessary to slow down GPL game cartridges.)

 

And. Random idea: supposing GPLMODE is implemented... it might not be too far a stretch to re-configure it with 99/8 ROMs/GROMs and memory map, booting to Extended Basic II. Imagine a 99/5 or 99/8 emulator, only running on real TMS99105 silicon, and physically on your desktop. (We'll call this the "Jurassic Park" option. Put that in the drawer for now.)

 

I'm trying to keep myself away from any ideas about HexBus peripherals and ports...

 

  • Like 5
Link to comment
Share on other sites

11 hours ago, HOME AUTOMATION said:

Hi FarmerPotato,

 

As this is one of my preferred subjects, I wonder how you're making out! :thumbsup: :thumbsdown:

 

This is a big, big project.  I'm working on the design, but its far from being a PCB. Most of the chips are here.  (except the RAM.) I keep reworking the PCB layout. And I have a priority of getting FORTI-2 out the door. But that shares a lot of work with the Geneve 2020. 

 

There will be tests of subsystems. The FPGA I have been working with for Geneve 2020 and FORTI-2 is on a BlackIce dev board. Most of BlackIce design, or the IceZero design (both open source hardware), will be repurposed  as "The Cube" which is like a North Bridge but but so much more. I will be using the 144-pin version of the ICE40HX4K (unlocked, 8K, with open source tools) and a removable 8-pin DIP EEPROM so you can get firmware upgrades manually.

 

However, I have yet to tackle such a scary project as ICE40HX4K on a board of my design. It's got 0.5mm pins. That's why I want to concentrate the tiny pin SMD chips on one square, which could be made separately and plugged in. (The rest could be a kit because it has 2.54mm thru-hole pins.)

 

There will be a test of a video "card". This is the easiest, except for the analog part. Includes research and work that I did toward "Gemini" twin 9958 design. There will be a simple socketed F18A option (no reason you couldn't put a 9918A/9929 in either) and a 9958 option. It will not be a "twin" 9958, I might come back to that later. I might go off to make a 99/4A plugin 9958 board, which was what Stuart was hoping when he sent me samples...

 

There is a lot of Verilog programming to do. I'm working on the FORTI-2 programming these days, which is good practice, and most of it goes into Geneve 2020 on the music side. FORTI-2 has a working SD card driver written in J1A swapFORTH. I have a working I2S interface generating stereo audio from wavetables on the Cirrus CS4344. It emulates and upgrades the 76489 sound chip; this is working on a basic level. The 76489 (aka TMS9919) is the only 9900 chip that I'm emulating, all the rest are genuine.  (I haven't done MIDI hardware since a few years ago, but I have a local friend to ask for help.)

 

There will be a test of the DRAM refresh logic, which I have yet to write in Verilog, but I can see how others have done it. 

 

There is a subsystem around the MSP430 which is an executive boot controller (like a BIOS, or the secret Pentium you can't access in all Intel PCs these days.) It's a TI 16-bit microcontroller with 32k Flash for programming.  I have the MSP430 ValueLine dev board with 20 pin DIP - I have not loaded eFORTH on it yet. It's currently sporting TI's BoosterPack for thermocouples--think Arduino shield. It's lots of fun, and I intended this toy to go into a manual PCB toaster oven, so I'm reluctant to re-flash it. Must buy more MSP430G2533 chips to flash with eFORTH and plug in.

 

There are two firmware parts necessary. One is the bitstream of the FPGA in the 8-pin DIP EEPROM. This is the controller of RAM and bus to all peripherals except the 9901 CRU and joysticks. The other  firmware is the MSP430 eFORTH. Both chips can be flashed with upgrades in-system using a cable. Both chips are removable (they are DIP socketed) for manual upgrades. All other software like MDOS or TI FORTH (a boot choice) come from the SD card. This is how I enable you to update the machine on your own using a PC, or just EPROMs in the mail. (And everything will be open source if you want to re-compile too.. I'm compiling on MacOS X but I'm told you can do it on a PC.)

 

eFORTH will be the language of the BIOS. eFORTH  on the MSP430 is described in the short book "Zen and the FORTH language" by Dr. Ting, who is very active in the Silicon Valley FORTH Interest Group. (You can watch meeting recordings on YouTube, search for SVFIG.) You will connect to the eFORTH "console" by a $9 FTDI cable on the joystick port (the kind SparkFun or Adafruit supply.) This lets you watch the boot sequence, upload new firmware, and write some simple tests. I wrote the firmware upload in FORTH  as an attempt at FORTH-ification of the BlackIce, trying to port MeCrisp FORTH back in April last year, but I haven't done any eFORTH yet.  

 

The jobs the 430 will do are: holding the RESET pin of the 99105 until RAM is loaded with startup 9900 code (there is no ROM), watching the FPGA load its bitstream (and maybe holding it while new firmware is being uploaded), and during run-time, hosting the PS/2 and maybe USB interfaces. The 430 will also provide analog inputs for experimenters (see previous post.)

 

I would love to off-load parts of the work, or at least testing, to experts here. I made a friend from BitBuilt who was bringing up the ICE40 from scratch.

 

The 99105 (3rd gen TI cpu, 6Mhz, replaces the 9995) is not getting much attention in this writeup, because I just received a sample and I have a lot to learn. I haven't build a complete 9995 microcomputer since the 80s, but I understand that part thoroughly. Unfortunately the 99105 won't be testable until the RAM controller is working.. unless I throw in another EEPROM and SRAM, plus bus latch, at which point it will look a lot like Stuart's Breadboard 99105. This will need a way to turn OFF the standalone 99105 mode.

 

Any of these subsystems might be tested by making unit PCBs to plug into the BlackIce dev board. Especially the RAM and video card and bus peripherals,

even the 99105. (Speech is another one.. I'm  really excited about digital speech out). The sound subsystem is being tested this way now.

 

 A lot of sub-boards can't all be connected at once, because I need all 99 pins of the FPGA.  BlackIce only leaves 64 pins for you to use, or 48 in the new version (a lot of pins are used up by its RAM.) It's unfortunate that, although the new version of BlackIce is made as a "Core" for dropping into other boards, it doesn't have enough pins to use as-is.

 

So, there is tons of work left to do before it will even be ready for 9900 software programming to begin. It's why I titled it "Geneve 2020" which might be barely doable.

 

You can see there will be a lot of FORTH in this machine. First the MSP430 BIOS, kind of like Open Firmware (FORTH based, found on PowerPC Macs.) You never have to see the BIOS messages unless you plug in a cable (I don't know if it can talk to the video.) Then there's a J1A on the FPGA which you can also talk to one day on RS232/3. J1A  runs the SD driver and FAT32 file system, which is already written in swapFORTH.  swapFORTH words will be callable from DSRs through an XOP instruction and communicate through shared memory. (For instance, there will XOPs for Level 1 Sector Access, maybe Level 2 Direct File Access, with Level 3 File I/O still in 9900 assembly.) Finally, third, there will be a bootable TI FORTH (or any 990 FORTH or other 99/4A flavor the authors care to port.) And fourth, in GPL, or Geneve FORTH you can run.  Perhaps all three FORTHs will need to be harmonized to one standard.

 

Of course MDOS will be the natural choice to boot to, but nothing says you can't boot to FORTH and then type MDOS to start up.

 

I repeat, there is tons of work to do before any work on 9900 software can begin. Making MDOS and GPL work will be a major task (along with writing and debugging the Geneve emulation in Verilog.)

 

SO there you go, a bunch of items on how its coming along. The first real results will come from prototyping on BlackIce, followed by serious PCB effort.

 

 

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

================== DESIGN PRINCIPLES for GENEVE 2020 ========================

  1. Use real TMS chips. 99105, 9901, 9902, 9958, 5220C. Use new TI brand parts where possible.
  2. Use FPGA to replace logic chips or invent new chips. (Emulate 9919 and 6100.)
  3. Maximize compatibility with MDOS, GPL, and hardware like cartridges and TIPI.
  4. Let users upgrade or hack on it. (memory SIMMs, Flash EEPROMs, PBox or Hexbus connectors, hacker plug-in board.)
  5. Make it fit in a 99/4A case, or a PC case of the user's choice
  6. Make it modular where possible (video for example). Use off-the shelf modules where possible (WiModem? ESP8266?).
  7. Make it kittable as far as possible (SMD soldering done by a manufacturer).
  8. All open source: hardware, FPGA firmware source, and use free toolchains. (KiCad for boards, Icestorm for FPGA, common 9900 tools)
  9. Make the parts cost under $300.
  10. Give it some blinkenlights.
     
  • Like 5
Link to comment
Share on other sites

5 minutes ago, Shift838 said:

can I have lights like Knight Industries 2000!

 

knight rider kitt GIF

 

Yes.

 

This would even work on a PBOX if you had enough cards.

 

Call BLWP @BLNKEN in some loop

LIGHTS
 DATA >1000,>1100,>1200,>1300,>1400,>1500,>1600,>1700,>1800,>1900
 DATA >1900,>1800,>1700,>1600,>1500,>1400,>1300,>1200,>1100,>1000
BLNKWS
 DATA 0,0,16
 BSS  26
BLNKEN DATA LIGHWS,BLINK0 
* CLR  R1      set this light
* LI   R2,16   clr this light
BLINK0
 MOV  @LIGHTS(R2),R12
 SBZ  7
 MOV  @LIGHTS(R1),R12
 SBO  7
 INC  R1
 CI   R1,20
 JLT  BLINK1
 CLR  R1
BLINK1
 INC  R2
 CI   R2,20
 JLT  BLINK2
 CLR  R2
BLINK2
 RTWP 
 
 

 

  • Like 4
Link to comment
Share on other sites

13 hours ago, HOME AUTOMATION said:
  On 8/5/2019 at 1:51 PM, FarmerPotato said:

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

Hi again,

 

As much as I wish I could follow all the wonderful directions this project is evolving towards, in intimate detail...:o The Geneve, TI MSP430, 99105 and TMS9919 emulation... all being subjects that have held my interest at times.:cool: However, my immediate situation affords me, limited participation... so, sorry if my interest seems micronic...:roll:

 

I am particularly interested in the tms6100 content, as I have long been attempting to isolate the LPC for certain words, accents and sound effects, for use in my own seemingly exciting(at moments) project ideas!:ponder:

 

;-)

Link to comment
Share on other sites

Careful... while the light strobe code will activate some RS232 LEDs (and maybe a few other card LEDs) not every peripheral ties the LED to cru [base] +[7] i.e.  SBO/SBZ 7.   Many (most?) cards are wired to turn on the LED when you activate the DSR ROM @>4000  i.e. [base] + [0]  i.e.  SBO 0/SBZ 0.  

 

Twiddling bit 7 could cause some strange things to occur with cards that utilize CRU bit 7 for purposes such as memory paging (e.g., HFDC) but more than likely will have no effect unless you also set bit 0. 

 

(The TI/CC/myarc Rs232 cards do not require the ROM to be enabled to access the other cru bits which is a nice 'feature'; the nanopeb doesn't follow this 'convention').

 

 

 

 

Link to comment
Share on other sites

57 minutes ago, InsaneMultitasker said:

Careful... while the light strobe code will activate some RS232 LEDs (and maybe a few other card LEDs) not every peripheral ties the LED to cru [base] +[7] i.e.  SBO/SBZ 7.   Many (most?) cards are wired to turn on the LED when you activate the DSR ROM @>4000  i.e. [base] + [0]  i.e.  SBO 0/SBZ 0.  

 

Twiddling bit 7 could cause some strange things to occur with cards that utilize CRU bit 7 for purposes such as memory paging (e.g., HFDC) but more than likely will have no effect unless you also set bit 0. 

 

(The TI/CC/myarc Rs232 cards do not require the ROM to be enabled to access the other cru bits which is a nice 'feature'; the nanopeb doesn't follow this 'convention').

 

Yeah, you're right, this wouldn't work well on the PBox lights. It would have to do what you said on specific addresses.. and put them in correct order for any particular Pbox too.


That was just a silly piece of code. I plan to have a 10-bar LED for the blinkenlights. Something like this would work there, probably at its own CRU base like >100 and aliased into >130E for the RS232 light.
 

 

Link to comment
Share on other sites


I'm having second thoughts about including the very fun TI MSP430 as an executive CPU. I think that an extra 9995 with 32K EEPROM/32K RAM would be fine as a boot manager and keyboard/mouse co-processor.

 

Reasons to use 9995 as an executive: 

  • 9995 is little brother to 99105, ideal as a microcontroller. Mac IIfx included two 10-MHz 6502s to handle serial ports, mouse, keyboard.
  • The HexBus disk drive included a 9995.
  • An MSP430 outruns the 99105 (16 bit, 16 MHz.) No fair.
  • 9995 runs same diagnostic firmware in FORTH. It might even be able to re-flash the EEPROM.
  • Still does the job of holding the 99105 in RESET until the FPGA and RAM is initialized, while permitting diagnostics.
  • Using 9901 CRU, it would have plenty of pins for I2C, SPI, USB, with interrupts and extra pins.
  • There could still be a chip with analog inputs on the "hacker board".
  • Bonus: the 9995 could talk to the 9901 owned by the 99105, to have 4A keyboard access at startup.
  • 9995 could generate useful interrupts to the 99105 like keypress available, mouse button, etc.
  • If it shares the VDP bus, it could update a mouse pointer sprite automatically. Turn this on/off with a CRU bit.

 

Cost

 

Takes up a lot more space. A 3x3" square for a minimal 9995 microcomputer. MSP430 is one 20-pin DIP.

 

MSP430 costs $2.50, no external chips needed, external DB9 adaptor optional with FTDI.

 

   $3.70 TMS9995 (ebay:polida2008) 

#1 $1.36 SST39SF010A-70-4C-PHE 128x8 Flash (Mouser) (use only 32K) 32-pin DIP
#2 $3.12 AT28C64B-15PU 8Kx8 EEPROM (Mouser) 28 pin DIP

   $2.54 AS6C62256-55PCN  32kx8 RAM
    ???? some external logic for CRU?
   $3.00 TMS9901 for lots of IO
----------
  $10.50

Costs 4 times as much, but keeps it more TI, plus you get an extra little 9995 computer under the hood that can run separately...
With an extra 9901, there will be no problem handling lots more peripherals.

 

PCB layout - maybe 3 inch x 3 inch

 c   c   c
###  ###  ###
#R#  ###  ###
#O#  #9#  #9#
#M#  #9#  #9#
     #9#  #0#
 c   #5#  #1#
###  ###  ###
#R#  ###  ###
#A#  c
#M#  ###
     ###

.1 spacing x 20 = 2 inches

1 row/col = .25 inch
12 boxes = 3 inch on a side
 

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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...