Jump to content
FarmerPotato

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

Recommended Posts

On 9/9/2019 at 9:14 AM, BeeryMiller said:

I'm not going to try and follow the memory accessing that was noted above.  There are two things to keep in mind.

 

In MDOS mode, ROMPAGE is not available to use the DSR's of the cards.  I guess someone could write a program that would use the DSR's, but that would be program specific and nothing has been written to date.  So, I/O is done directly through MDOS in MDOS mode.  Memory access is required.  I would think the decoding of the extra three lines would be necessary.

 

In GPL mode, standard access is through the MDOS master DSR.  Only when you use ROMPAGE, will GPL mode ignore the master DSR.

 

Beery

 

 

I think it will be ok. You brought up the address decoding a while back and I thought about that problem. My solution is that the Pbox connector will see only standard 4A signals, nothing Geneve specific.

 

GPLMODE (and MDOS) will still have a master DSR. I'm allowing for card DSRs in either GPLMODE or even MDOS (if you want.)  I think it will emulate the ROMPAGE behavior. (you could turn off the master DSR or replace it with one having only a few device names like SD1 for the built-in SD card. Or place it last so the master DSR copies of DSK1, HDS1 and WDS1 etc are a last resort.)

 

None of the PBox memory bus sees accesses in the 32MB DRAM space. The extra three lines are never activated. Effectively, there is a separate 64K space just for the Pbox and other devices in GPLMODE. Bank registers have the E bit to direct  memory access to either DRAM or PBox port. (So a SAMS card in the Pbox would work in GPLMODE... double mapping!)

 

 

Share this post


Link to post
Share on other sites

9995 co-processor

 

Here is the design for the I/O co-processor board that fits in the left edge of the console.

 

Exec9995-3D-2.thumb.png.425c78d6ae2885deff0a549430fee4ef.png

 

Exec9995-2D-2.thumb.png.49ebdae67fe9197dc70065361d8536f0.png

 

Dimensions: About 75mm x 110mm or less than 3" by 5". Ignore the red/green traces, I haven't seriously routed the board.


Short description

 

The co-processor controls startup process like a BIOS would. It accepts uploads of new firmware over the serial port and flashes the EEPROMs. It runs the keyboard and mouse ports. It puts the "Personality" code into page 0 of DRAM to prepare the 99105 to boot. Personality can be for MDOS/UNIX/FORTH or whatever; you choose one in the BIOS. So, it handles boot, and then offloads some processing chores from the main CPU.


High-speed Serial Port


The co-processor replaces the joystick port with a standard DB9 serial port. (The joysticks will plug in somewhere else. This removes the need to cut more holes in the console.)


The serial port is a 9902, but clocked at 1.8432 MHz like a PC 16550 serial would be. This gives it perfect accuracy for baud rates 57.6k and 115.2k. The usual 9902 with 3 MHz clock can't hit these precisely enough (4% and 8% error resp.) Hence the name "high speed serial port." I am not changing the other RS232 ports (DB25) for software compatibility.  


A firmware upload will take 15 seconds at 115.2k. This makes my life better!


After boot is done, I'm not sure if the serial port will continue as a debugging console, or become an RS232/3 peripheral. This port would not be compatible with existing software, but standard DSR access to RS232/3 would be fast enough for 115.2k and have a large buffer.


Peripherals


The two locking connectors are I2C buses. One goes to The Cube to send in key/mouse info and anything else. One is free for other uses! For instance a temperature chip or anything really that speaks I2C.  I wrote an interrupt handler to think through how multiple channel I2C would work.


The 2x15-pin connector is a video card connector. (it also routes to the PS/2 and USB connectors.)


There is also a connector for an FTDI serial cable. This is an alternative to the DB9 serial port.


I killed off the 9901 CRU in favor of 8-bit input and 8-bit output registers attached to CRU. Exactly like the PIO port in the RS232 card.  These run the peripherals. I just didn't need the 9901 anymore. Some reasons: I didn't need all the interrupt handling (just one interrupt), and the 9901 timer is superceded by the 9995 on-board timer.  Also the 9901 takes up a lot of space.  (The Geneve 2020 will still have a 9901 for MDOS and 4A compatibility.)


Pros/Cons of co-processor


The 9995 co-processor replaces my original idea to use the TI MSP430 to handle keyboard/mouse. Here are some pros and cons.


Reasons to have a co-processor at all


Pro: saves FPGA pins
Pro: Can add more devices to the I2C bus after all the FPGA pins are used up.
Con: the FPGA would be far more perfect at doing this job but cost a few more pins.
Pro: the 99105 would have to continually service the ports to multitask I/O and computing


Choosing the 9995 for the I/O coprocessor


Pro: can handle one high-speed 9902 with no distractions from interrupts
Pro: it keeps things real 9900 family.. but would anyone notice?
Pro: it provides a friendly BIOS prompt, using the video card
Con: the 99105 could do all these jobs with some switcheroo at boot, but would add cost too (formerly the 9938 handled bus mouse)
Con: requires its own Flash and RAM
Pro: You can use it as a standalone computer!
Pro: "hardware" mouse sprite maybe, moves smoothly in background
Con: it costs $25 and takes up a lot of space
Pro: FORTH interpreter lets you write diagnostics


Using the TI MSP430 for the I/O coprocessor


Pro: it has built-in I2C and SPI
Pro: onboard 32K flash for one personality
Con: its kind of cheating again because it's a 16MHz 16-bit CPU
Con: it might run out of pins (budget seems to be ok for keyboard/mouse)
Con: not enough pins for video
Pro: it costs $3 and is just one chip


Video Card Connector


The co-processor has a video card connector that will allow the co-processor to share the video card with the main board. At startup time, you can interact with the co-processor by serial port, or the screen/keyboard. Just like the BIOS on a PC. It may also allow the co-processor to implement mouse-position-to-sprite in the background for really smooth mouse motion (no mouse stuttering during disk access, for instance.)  Yay for co-processor.


The video card connector is a 30-pin MxMod standard that I am using. It facilitates 3 uses:

 

  1. Plug the video card into a BlackIce dev board for testing
  2. Plug the video card into the Co-processor board for the development process
  3. Plug the video card into the Geneve 2020.
  4. Plug the video card into the Co-processor and have yourself a stand-alone computer!

 

The video card can be made from several things:

 

  1. Standard 9918A socketed with 16K memory
  2. F18A or Mk2 (plugs into 9918A socket..)
  3. 9938 or 9958 with 128K memory. Extra ports (palette write) are implemented.
  4. Twin 9958 with 256K memory and superimpose function. (This is my favorite.)


There will be options for the right kinds of video ports in each case. A chosen port option will mount on the back panel and connect to the video board by cable.  One option will be Composite+RGB with selectable CSYNC or VSYNC.  F18A will use its own thing.

 

 

Notes

 

11. The co-processor is essentially Stuart's Breadboard 9995 plus video and I2C.

12. All components on this board are thru-hole. The PLD and Flash are programmable in the inexpensive XGPro (TL-866 II). So it is perfect for kit form.

 

 

 

  • Like 3

Share this post


Link to post
Share on other sites
1 hour ago, FarmerPotato said:

GPLMODE (and MDOS) will still have a master DSR. I'm allowing for card DSRs in either GPLMODE or even MDOS (if you want.)  I think it will emulate the ROMPAGE behavior. (you could turn off the master DSR or replace it with one having only a few device names like SD1 for the built-in SD card. Or place it last so the master DSR copies of DSK1, HDS1 and WDS1 etc are a last resort.)

 

I need to ask if this "Geneve 2020" is supposed to be compatible with existing Geneve MDOS programs? 

 

I seriously doubt you can implement "rompage" in MDOS mode. The reason for this is that anything that uses file I/O will fail as there is no set standard where in memory the DSR calls will write code unlike the PABS one can setup in GPL (TI-99/4A) mode.  There is a 21 bit address space for the 2 MB range and any program can send data into any memory range of the existing mapped 64K or into the upper memory page ranges.  Existing TI-99/4A hardware in a Geneve, in MDOS mode, has no awareness there is a Geneve; thus the reason the master DSR was needed.

 

As far as MDOS mode accessing additional memory, while I think new programs could be written to use a 32 MB range, no existing program would be able to handle anything above the 2 MB range as each page is mapped on a 8 bit, one byte page, max 256 pages.  As Tim eluded earlier, most programmers manually map their memory pages instead of using the XOP's to map memory so tweaks to MDOS and its memory mapping routines will not solve backwards compatibility and thus my first question above.

 

Now, if your 99105 design plans are to tweak MDOS to work with it in a new "non Geneve 9640" environment, no problems.  Source code is available for you to move forward.  My only thoughts are there will be very few programs that run on a Geneve 9640 in MDOS mode that would work with it.  Different story if you can take the 99105 to emulate the TI-99/4A environment in what we call GPL mode on the Geneve.

 

My biggest concern here is do not make the project so ambitious it can not be achieved in a realistic timeframe.  No problem if you can meet the basics and have the underlying hardware design capabilities to expand.  

 

Heck, I would be happy with just new Geneve compatible hardware and then be able to build upon it as time permits.

 

Beery

 

 

 

 

 

 

Share this post


Link to post
Share on other sites

Hi Beery,


Those are great questions. I'll tell you what I've figured out so far.


The goal is absolutely 9640 compatibility. And GPLMODE under that. Any extensions are gravy. Otherwise there would be little or no software... there may be some tweaks to MDOS code, but I will emulate the environment MDOS expects as much as possible.  The main goal of the project is "Geneve inside a 4A case" though it will be workable inside any other case.

 

Exceptions:

  • Support for SD card drives
  • The GPL program will require a change in the way it initializes, because several pages are special. I think.

ROMPAGE behavior would be for GPLMODE. I was just wondering out loud when I said MDOS mode could map in a Pbox DSR--there is little point. The DSR would not run, because all these things are only present in GPLMODE: PAD, VDP layout, ROM routines.. IF you just want to LOOK at the DSR ROM or write to registers, there is a way to get it mapped in from MDOS. (You could play with external SAMS memory for instance.) But it's a silly idea. (BTW, SAMS will be emulated for GPLMODE.)


I had thought to rely on all mapping going through an XOP.. you point out that I must support users writing to bank registers. So to keep maximum compatibility, the bank registers will take 8 bit values. There is some magic that happens:


Essentially, the 99105 supervisor assigns MDOS to a 2MB space anywhere in physical RAM. MDOS sees just the LS610 memory mapper. MDOS keeps 8-bit page numbers. Very compatible. 


Behind the scenes, the real bank registers in the North Bridge will be 16 bits. (13 address plus 3 mode bits.) When you write an 8 bit value to the MDOS bank register, one copy is stored (in case you read it back) but it will be forwarded to the 16 bit register with a physical base address added on.


The physical base address will be constant while MDOS executes.  Again, it points to a 2MB block allocated for MDOS. MDOS can't get out of this space. (Except may by some new XOP calls.)


(I have written the Verilog code for the LS610 memory mapper that takes 8 bit values and tested it on a 512K SRAM on the 4A sideport. So this is something I'm confident about.)


What can you do with all that extra RAM?

 

  • Nothing. Buy just 2MB (though 64K would be taken by the supervisor.) (Only $20 more for 32MB.)
  • Use a new utility to load a 512K cart into GPL without stealing memory from MDOS. 
  • Create a RAMDISK that doesn't reduce available memory in MDOS.
  • Load more than one instance of MDOS, with a key to switch between them. This might even enable multitasking.. hmm.
  • Emulate SAMS in GPLMODE with an extra 2MB.
  • Run UNIX
  • Load a 500K library of samples for the sound chip (see https://www.adventurekid.se/akrt/waveforms/)
  • Load very large audio files for playback in the background (sound chip can read directly from RAM)
  • ???

 

Schedule

 

I keep a list of subprojects. I'm working on two of them, co-processor and sound. I've prioritized them into NMI, High Value, and Nice to Have. My interrupt mask is 0001, which lets me work on Necessary Minimum Implementation and High Value. For now, there are no dates, but I will share progress here.

 

 

  • Like 4

Share this post


Link to post
Share on other sites

Well, this project is very exciting... nowadays this thread is the one I looking forward to read.

You got me at the sound and music capabilities the Geneve 2020 will have, it has been the one thing I have missed most on the TI-99 and the Geneve.

My imagination has started, it´s not expectations, but it feels good to dream about what might be possible to create with a computer like this.

 

Share this post


Link to post
Share on other sites

I'm just looking forward to having something on my desk that doesn't take up massive amounts of space and has the ability to pretty much hold all software ever made for it on one storage device, not to mention being able to play with speeding up old Basic/XB programs and seeing what new innovations people will come up with! :D Of all the projects I'm following this is the one I'm most looking forward to!

Share this post


Link to post
Share on other sites
15 hours ago, FarmerPotato said:

Hi Beery,


Those are great questions. I'll tell you what I've figured out so far.

I read your response and thanks very much for the reply.  Sounds like you have very reasonable goals.  I was beginning to worry you were biting off more than one person could chew.

 

Beery

Share this post


Link to post
Share on other sites
17 hours ago, Nick99 said:

Well, this project is very exciting... nowadays this thread is the one I looking forward to read.

You got me at the sound and music capabilities the Geneve 2020 will have, it has been the one thing I have missed most on the TI-99 and the Geneve.

My imagination has started, it´s not expectations, but it feels good to dream about what might be possible to create with a computer like this.

 

You are going to love the next post.

 

 

Share this post


Link to post
Share on other sites
3 hours ago, BeeryMiller said:

I read your response and thanks very much for the reply.  Sounds like you have very reasonable goals.  I was beginning to worry you were biting off more than one person could chew.

 

Beery

I am biting off too much!  I've got to figure out how to manage this project to ship the Necessary Minimum Implementation.

 

Keep the questions coming.

 

Share this post


Link to post
Share on other sites


Sound System for Geneve 2020 and FORTI-2 for TI-99/4A


Goals

 

 

  • Upgrade the 76489 sound chip to 12 voices with loadable wavetables
  • All-digital internally
  • Add stereo panning
  • MIDI interface
  • Use CS4344 stereo DAC chip
  • Add an FM synthesizer
  • Retain compatibility with TI-99/4A and FORTI card

 

Hardware


First of all, the 76489 sound chip is upgraded to 4 chips or 16 voices. These are accessed as the FORTI card by decoding 8400-841F.  This is one chip I'm fully emulating. The original sound will be sampled (because it is not a perfect square wave.)


Second, there is a full synthesizer based on wavetables and maybe FM synthesis.


Third, there are ports for MIDI IN, MIDI OUT, MIDI THRU. These are vintage 5-pin DIN. Not Gameport or Mini-Din5 or USB.


MIDI Definitions:


Controller is a MIDI device that sends MIDI OUT events, like a keyboard. A controller by itself does not produce sound.
Synthesizer is a MIDI device that can produce sound in response to MIDI IN events.
MIDI IN is the input port.
MIDI OUT is the output port, sending commands generated by the device.
MIDI THRU is a simple pass-through connector for forwarding MIDI IN to the next device in a daisy chain.

 


A typical "synthesizer", for example a Yamaha PSR or DX7, is both a controller and a synthesizer. As you press keys, it plays the sound. It also acts as a controller by sending to MIDI OUT.  It plays sound in response to MIDI IN events. 


An synthesizer by itself does not have any keyboard, and relies on MIDI IN. It may have buttons. Examples are rack mount modules like a drum sequencer.


There are controllers with breath input, for example a MIDI horn or the infamous MIDI bagpipe.


Software

 

Let's begin with what the TI BASIC interface will look like. 


Understand that when I say CALL SOUND, that any assembly language or GPL program is also covered, because they boil down to writing commands to the sound chip.


Here's a short example:

CALL MIDIMODE(1)
CALL SOUND(250, 262, 0, 330, 0, 393, 0)


Plays a C major chord on the synthesizer.


In all MIDI modes involving the sound chip, frequency and attentuation are translated to the closest MIDI note number and velocity.  This includes any sound chip access by CALL SOUND or access from assembly or GPL, because it works at the chip level.

 

CALL MIDIMODE(1) convert sound chip to the MIDI synthesizer; translate CALL SOUND
CALL MIDIMODE(2) play MIDI IN on the synthesizer
CALL MIDIMODE(3) do both 1 and 2
CALL MIDIMODE(4) play MIDI IN on the sound chip: chiptune mode (up to 12 voices)
CALL MIDIMODE(8) enable MIDI OUT. Play CALL SOUND through it.

CALL MIDIMODE(0) turn off MIDI, go back to TI-99/4A mode only


 

CALL MIDIMODE persists after exiting TI BASIC!

 

Internal Details of MIDIMODE


Internally this is what happens:

CALL SOUND     \ 2 mode bits / sound chip   \ 1 bit  -- MIDI OUT
MIDI IN enable / switch      \ synthesizer  / enable  


There are really 4 bits used in different combinations:

1 Enable synthesizer for CALL SOUND
2 Enable MIDI IN (default to synthesizer)
4 Route MIDI IN to sound chip instead of synthesizer (requires mode 2)
8 Enable MIDI OUT for CALL SOUND


Possibilities:

1 Upgrade CALL SOUND to the synthesizer
3 Play CALL SOUND and MIDI IN on the synthesizer
2 Play MIDI IN on the synthesizer, CALL SOUND on boring sound chip (game mode)
6 Play MIDI IN on the boring sound chip (chiptune mode)
8 Use CALL SOUND as a controller only
9 Play CALL SOUND on the synthesizer as well as sending to MIDI OUT (recording studio mode)


Other combinations are possible but weird:

5  chiptune for MIDI IN, synthesizer for CALL SOUND
4  duet mode: chiptune for MIDI IN, CALL SOUND as usual plus MIDI OUT


Use Cases


CALL MIDIMODE(1)
BYE
play Alpiner
Theme music goes to synthesizer!


CALL MIDIMODE(2)
BYE
Stream Holst's 'The Planets' from iPhone to MIDI IN
play Parsec
Enjoy original sound effects plus background music

 

Tracks and Patches


Each sound chip channel (3 tone, 1 noise) can be assigned a MIDI track and a General MIDI instrument (patch):


CALL MIDITRACK(1,1,3,4)
CALL MIDIPATCH(1,1,65,113)


Here, voice 1 and 2 are basic piano #1 on track 1, voice 3 is flute #65 on track 3, the noise is poorly mapped to the MIDI percussion set.


When any program sets a frequency and attenuation, there is a Note On event. (This requires a small delay to see if an attenuation byte follows the frequency.) Frequency is mapped into the nearest MIDI note number. Attenuation is mapped into Velocity.


If attenuation is silence, a Note Off is sent. The CALL SOUND duration is the time between Note On and Note Off events. Duration can be negative or positive. As expected, a negative duration in BASIC means return immediately without waiting, and the next CALL SOUND replaces the note, causing a Note Off/Note On.

 

Luftpause


In choral music there is a pause for breathing at the end of the measure. In a lot of MIDI tracks, notes are cut off a bit early (for sustain to take effect?) This can be simulated for every note with

CALL MIDILUFT(N)


where N is the number of milliseconds to cut off from each note. The sound chip isn't programmed with a duration, and it can't bo back in time. So this implies that MIDI output Note On events are delayed by N time while Note Off events are sent immediately. This results in a delay relative to other players that may be connected.. it's a kludge, but ok if you are the only controller. If you want real breaths at the ends of measures you have to make a rest yourself.


Stereo

CALL STEREO(-16, -12, -4, 8)


Set the left-to-right position of the 4 voices. There are 33 steps. By default all voices are centered at 0.

 

Assembly language DSR access


In assembly, all of the  configuration is done through the DSR.


There is a MIDI device. The File Mode bits in the OPEN opcode correspond to the values shown for MIDIMODE. The Read opcode gives you buffered input so far. The Write opcode outputs MIDI bytes. Close sends any needed Note Off commands. Otherwise it is up to you to read/send all the raw bytes.


Since there is a DSR, you can do this from BASIC, but you have to send chars for bytes:
 

CALL MIDIMODE(0)
OPEN #1:"MIDI",DISPLAY, VARIABLE 80, UPDATE
A$ = CHR$(57)&CHR$(63)&CHR$(129)&CHR$(60)&CHR$(63)&CHR$(129)&CHR$(64)&CHR$(63)
PRINT #1:CHR$(129)&A$
FOR I=1 TO 50
NEXT I
PRINT #1:CHR$(128)&A$
LINPUT #1:A$
PRINT #1:A$
CLOSE #1

Plays an A minor chord, then plays whatever has come in so far on MIDI IN.

 

Bug: how do the MIDIMODE bits get set without BASIC filemode clobbering them?

 

Not limited to 4 channels

 

MIDI notes will play on any available channel.

The sound chip emulation isn't limited to any particular channels, but defaults to 1-12 anyhow.

There are 16 or more channels, however many I think are feasible.

 

Future want list

 

  • I want to create a MIDI channel to control the speech synthesizer
  • I want to implement FM synthesis
  • Maybe just include a Yamaha OPN series FM synthesizer
  • Fancy software
  • Play back large audio samples
  • Add a microphone/line input? Add CS5343 A/D converter
  • Full emulation of Yamaha DX7
  • Full emulation of Kawai K-5
  • Full emulation of Ensoniq ESQ-1 (these are all the vintage instruments I played in the 80s)
  • ESQ-1 is by the Commodore SID folks and used in the Apple IIgs

 

MIDI hardware implementation


There will be another 9902 serial chip driving MIDI. Pullup to 5V, not RS232 levels, so no MAX232 needed.


MIDI baud rate is 31250. This divides perfectly into the usual 9902 3MHz clock. In fact it divides perfectly in any of the 4 modes.  3MHz with any stage divider combo: 3,4,24, or 32 then divided by 31250: Period is integer 32, 24, 4 or 3. Compatibility assured!


Here's a schematic for MIDI:
https://ccrma.stanford.edu/~gary/controllers/midi.htmlTo be Retro, keep the MIDI THRU port which is omitted nowadays.


BOM


6  resistor 220 ohm
1  Diode
1  6N138
1  (2 of N) buffer drivers on MIDI OUT, MIDI THRU.
1  9902 serial chip

 

Notes

 

13. All of this spec was developed for my FORTI-2 product for the TI-99/4A.  There should be a release of this hardware and DSR for use on the TI-99/4A first. I've been working on this in hardware and software for quite some time now.

 

References


MIDI command sequences
https://www.midi.org/specifications-old/item/table-1-summary-of-midi-message


MIDI hardware circuit
https://ccrma.stanford.edu/~gary/controllers/midi.html

General MIDI GM-1 sound set
https://www.midi.org/specifications-old/item/gm-level-1-sound-set


Adventure Kid Single-Cycle Waveforms
https://www.adventurekid.se/akrt/waveforms/
 

Sample implementation of CS4344

https://store.digilentinc.com/pmod-i2s2-stereo-audio-input-and-output/

 

 

Edited by FarmerPotato
LINPUT
  • Like 3

Share this post


Link to post
Share on other sites
3 minutes ago, FarmerPotato said:

I am biting off too much!  I've got to figure out how to manage this project to ship the Necessary Minimum Implementation.

 

Keep the questions coming.

 

Right now, at least what you describe, sounds feasible.

Share this post


Link to post
Share on other sites
6 hours ago, Tornadoboy said:

I'm just looking forward to having something on my desk that doesn't take up massive amounts of space and has the ability to pretty much hold all software ever made for it on one storage device, not to mention being able to play with speeding up old Basic/XB programs and seeing what new innovations people will come up with! :D Of all the projects I'm following this is the one I'm most looking forward to!

I was thinking yesterday while picking out an EEPROM chip that the user could replace (it has to be a good old thru-hole 8-pin DIP)

(So they can get it through the mail if necessary)

 

What if all the software ever made were permanently installed on one massive EEPROM? 

 

This is probably all kinds of trouble. Better to just let the user have everything on their SD card.

 

 

  • Like 1

Share this post


Link to post
Share on other sites
On 9/11/2019 at 12:41 PM, FarmerPotato said:

I was thinking yesterday while picking out an EEPROM chip that the user could replace (it has to be a good old thru-hole 8-pin DIP)

(So they can get it through the mail if necessary)

 

What if all the software ever made were permanently installed on one massive EEPROM? 

 

This is probably all kinds of trouble. Better to just let the user have everything on their SD card.

 

 

There would have to be an "unofficial" image of the EEPROM or SD circulating among enthusiasts :D I like the replaceable EEPROM idea, the image could have versions like MAME does as new things turn up. 

Something would come together eventually, it's just a matter of what kind of device it would be for and whether it's large enough to handle it, which I imagine shouldn't be an issue given the capacities with modern hardware. I used to have a pretty big collection of stuff on cassette and had catalogs of others that I always wanted to try, I'd love to take a stroll down memory lane one of these days through a big repository of them knowing they're pretty much all there.

 

Edit:

 

Thought I'd throw these links up here, it's about a similarly impressive project called the Commander X16. It's a whole other animal as compared to the Geneve 2020 as they're aiming for a Commodore 64-based system but I figured (assuming you're not aware of it already) you might find it interesting:

 

Part 1: 

 

 

Part 2: 

 

Edited by Tornadoboy

Share this post


Link to post
Share on other sites
On 9/11/2019 at 12:38 PM, Tornadoboy said:

 

Edit:

 

Thought I'd throw these links up here, it's about a similarly impressive project called the Commander X16. It's a whole other animal as compared to the Geneve 2020 as they're aiming for a Commodore 64-based system but I figured (assuming you're not aware of it already) you might find it interesting:

 

 

Those were really interesting and fun. (I recognized Robin Harbron, who is the author of Minima for the VIC-20)

 

We have different design goals, but it made me think about the value of exposing everything vs hiding behind chip emulation.

 

I plan to have the 99105 run in supervisor mode, and a mysterious North/South Bridge emulating memory mapped registers and I/O devices.

But everything will be open source and documented. If you look into the innards, you might come out wanting to learn more about computer architecture and learn Verilog.

 

I don't know if the price will be prohibitive. When I try to add it up, it keeps going up to $200 without video. The video is the single most expensive part--I'm costing in my own 9958 option or a F18A mk2 that the user will buy. 

 

Share this post


Link to post
Share on other sites

Today I worked on a DRAM test board. My design is for 30 pin SIMM FPM DRAM in 2, 8 or 32MB.

 

There is a 20 pin interface. I am optimizing the number of pins everywhere! The SIMM is a 5V device, my North Bridge is 3.3V, so I use LVC245A buffers for data, and HCT573 latches for address.  There is a 2-pin jumper for the 5V supply. The other 3 connectors are standard PMOD with 3.3V on each.

 

Address (12+12 bits) and data (16 bits) are multiplexed. The address lines are latched before activating RAS or CAS. The data lines are buffered early enough and bus contention is avoided. 

 

I'm taking the approach of building and testing one module at a time. Other than the connectors, this will move directly into the Geneve2020. In fact, there might be a prototype eventually built out of all the test modules! This module is 55mm x 100mm.

 

Here are tonight's pretty pictures from KiCad. There is no 3D model for the SIMM socket.  I created the symbol and footprint from the technical drawing.

 

GeneveDRAM-2D-1.thumb.PNG.8506588429597bb5a9ab9784b71a2bcf.PNGGeneveDRAM-3D-1.thumb.png.57c4418829bfc504f02c29c34389e989.png

  • Like 5

Share this post


Link to post
Share on other sites
6 hours ago, FarmerPotato said:

I plan to have the 99105 run in supervisor mode, and a mysterious North/South Bridge emulating memory mapped registers and I/O devices

 

Wouldn't the mode switch (user/supervisor) be a job of the operating system? I'd like to see a nicely seperated kernel and a userland.

  • Confused 1

Share this post


Link to post
Share on other sites
On 9/15/2019 at 5:28 AM, mizapf said:

 

Wouldn't the mode switch (user/supervisor) be a job of the operating system? I'd like to see a nicely seperated kernel and a userland.

I was sloppy. What I meant was some code will run as supervisor. As a user, you would not be able to see or poke at this except by recompiling the O/S. So it is a layer removed from being hands-on. In those interviews, people said they value interaction with all the internals.

 

I guess I could build in back doors. Like an XOP that lets the user load code into supervisor space and run it! A big red LED would turn on if you used that. Or a back door that lets you map the 64K of system data in for direct meddling. There could be a literal back door switch on the back to enable this. You wouldn't have to find exploits, they would be built-in.

 

There will be a kernel and userland. Kernel is a separate 64K code and 64k data space.

 

Here's a 3-layer stack:


North Bridge

 

Physical RAM 2 to 32MB
16-bit bank registers
Bits that define addresses as RAM, ROM, Pbox or memory mapped I/O

 

Kernel - privileged bit

 

"Page 0" code (PSEL=0) (64K)
"Page D" data (PSEL=1) (64K)
Privileged code run during any INT, any XOP or MID opcode.
This includes the MDOS XOPs which may be rewritten for optimization.
Memory manager for 32MB physical DRAM.
Privileged CRU addresses (e.g. 16 bit bank registers)

 

User Space (multiple)

 

Up to 2MB slice of physical memory, code and data mixed
8-bit bank registers

MDOS executes here mostly, except XOPs go back through kernel.
GPL executes here when set up by MDOS.

 

Other O/S concepts

 

I have not yet thought through in detail how the kernel might provide multitasking. There is protected memory: kernel and each user space are separate. I'm allowing for copy-on-write data pages and shared memory.
 

VDP multiport


I thought through this in detail. South Bridge can remember the VDPWA and restore it, so there can be multiple writers to the VDP that don't wreck each other's writes and reads. These could be the I/O coprocessor and the main CPU.  Or different user space processes. This allows "hardware mouse" sprite.

 

Given an F18A, write access can go much, much faster than the 4A. It would be possible to implement a DMA (direct memory access) controller that transfers from DRAM to VDP at 3 to 20 MHz.  At 3 MHz, it would take 4 ms to copy a 12K bitmap (read or write.) You could use this for page flipping, or to move data sets to/from the GPU.

 

DMA is independent of the CPU, and in this case would not have to add any wait states to the CPU: access would be prioritized, or multiple time slots would make contention nonexistent. 

 

VDP transfer priority. Each interrupts the lower queue, saves and restores VDPWA.

1. Mouse sprite (if turned on) interrupting on any position change

2. CPU access (instructions, data)

3. DMA transfer (sets CRU bit when done)

 

The DMA controller chip made by TI  is tough to find, and anyway it halts the CPU. I read about it in TI's 16-bit Microprocessor Systems textbook. (I'm sure its in the 9900 Systems Family Guide somewhere.) Anyway, this DMA would be in the North Bridge (DRAM) talking direct to the South Bridge (VDP etc).

 

DMA is also for DRAM to DRAM. For instance, the MDOS move memory XOP could be re-written to use DMA, which would be a free benefit.

 

  • Like 1

Share this post


Link to post
Share on other sites

Here is a current System Diagram.

 

SystemDiagram-1.thumb.PNG.7fa1472a3a8c5f419f4c35539cac78f9.PNG

 

The names come from PC terminology for North and South bridge, for fast RAM and slow peripherals. But it also describes the 4 sides of the ICE40HX4K FPGA, each having 36 pins. In the KiCad schematic, the FPGA symbol is split into 4 separate symbols (A,B,C,D) for the sides. Each goes on one of 4 hierarchical schematic sheets.
 

 

  • Like 1
  • Thanks 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...