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

[+FarmerPotato]

1 hour ago, HOME AUTOMATION said:

Hi again,

 

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

 

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!

 

 

That's OK. You will be in luck when I have the TMS5220C + 6100 dumper on a test board. Maybe I'll do that first...

Although, you can already get the 6100 ROM dump, or access it all with SPGET. The real learning is parsing the LPC bits and understanding what they mean.

 

What is micronic?

 

[+FarmerPotato]

On 8/7/2019 at 5:45 PM, Tornadoboy said:

 

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

 

Thinking about this.. boot choices might be MDOS, FORTH, even UNIX (Stuart has one). Would you want it to boot to the TI-99/4A title screen? That would be done by writing an AUTOEXEC file for MDOS:

GPL <your list of cartridges here>

Multiple cartridges on the 4A screen.. separate GROM carts should be OK. Might take some modifications.

 

Would you want it boot directly to a TI Extended Basic, or Myarc Advanced Basic prompt? That should be doable.. there would be a trick where the AUTOEXEC could pre-stuff some keypresses. (sneaky)

 

You could probably have separate scripts under MDOS to go directly to your cartridge of choice in GPL.

For instance just type "EA" at the prompt and it goes into EA. Or define a hotkey like F6...

 

However,  I see most of the functions of EA being replaced by newer, better choices like GENASM. Surely a GPL program launcher instead of LOAD PROGRAM FILE or LOAD AND RUN.

Maybe even a serial connection that downloads assembled code from a PC quickly, so you can use Ralph's excellent xdt99.

 

 

[+mizapf]

1 hour ago, FarmerPotato said:

The real learning is parsing the LPC bits and understanding what they mean.

 

Remember to study the MAME emulation of the TMS52xx family. It's not from me, though, so I cannot provide any help here. But I know that the guys drew a lot of knowledge from the patents and uncapped chips and put that in the code.

[Tornadoboy]

More comments from the peanut gallery:

 

Would it be possible to make it so you could set the speed through commands in the software, maybe even in basic and XB? I'm thinking of some of the games where it takes ridiculously long times for it to calculator/process stuff between game play but speeding up the actual play itself might not work out well and be too fast as well as mess up music and sound effects, it would be cool if it were possible to insert commands in these programs to speed it up at parts where it would be useful then slow it down to normal in others, or better yet be able to do it in degrees. An example would an old basic game that while having potential would normally just plod along ridiculously slow to the point where the game is barely tolerable, if that. One could go through the code and custom taylor the speed to go full throttle to get through all the annoying parts but then slow down to normal or above normal speed to lesser degrees for character movement and music. 

Edited September 4, 2019 by Tornadoboy

[+FarmerPotato]

3 hours ago, Tornadoboy said:

More comments from the peanut gallery:

 

Would it be possible to make it so you could set the speed through commands in the software, maybe even in basic and XB? I'm thinking of some of the games where it takes ridiculously long times for it to calculator/process stuff between game play but speeding up the actual play itself might not work out well and be too fast as well as mess up music and sound effects, it would be cool if it were possible to insert commands in these programs to speed it up at parts where it would be useful then slow it down to normal in others, or better yet be able to do it in degrees. An example would an old basic game that while having potential would normally just plod along ridiculously slow to the point where the game is barely tolerable, if that. One could go through the code and custom taylor the speed to go full throttle to get through all the annoying parts but then slow down to normal or above normal speed to lesser degrees for character movement and music. 

Yes.

 

1. Beery was asking about a Turbo key. Since the keypresses go through the FPGA, it's possible to give keys magic side effects, like ctrl-F7 to toggle speed. (Probably only from a full-size PS/2 or USB keyboard, not the 99/4A original keyboard.)

 

2. It would be possible to add utilities to a DSR ROM, so that a CALL SPEED(0) for example could set FullSpeed mode, CALL SPEED(1) sets it back. I don't know how many speed levels there will be, except that speed will be finely calibrated for different modes TI-99/4A, Geneve, and something in between (modified TI-99/4A or 99/8 for instance.)

 

 

[HOME AUTOMATION]

11 hours ago, FarmerPotato said:

 

That's OK. You will be in luck when I have the TMS5220C + 6100 dumper on a test board. Maybe I'll do that first...

Although, you can already get the 6100 ROM dump, or access it all with SPGET. The real learning is parsing the LPC bits and understanding what they mean.

 

What is micronic?

 

My understanding is that tms6100 is mearly a reference to the I.C. series... with specific 61xx numbers for custom ROMS. I believe other series #s exist for the same I.C.s as well. I am aware that some PHROMS/LPC DATA have been bit reversed as well, creating some permutations of how to isolate particular LPC segments(words) and lengths.

Despite having a ROM dump containing the code I wish to isolate(mixed with other stuff too), and even having some possible matching strings to compare, I have failed on several attempts. I usually try to take short-cuts, but that's not always the correct strategy. I have some other ideas on how to isolate LPC segments simply, but haven't been able to get around to developing them yet.

mi-cron-ic, adj. 1. Of or pertaining to limited scope of vision. 2. A value which can only be determined in direct relation to my attention span. 3. An inability to pan out far enough to see the forest for the trees. 4. Leading the life of a micronic.

 

mi-cron-ics, n. (used with a singular verb). 1. The study and establishment of one's own, as well as others' micronicies!

[+FarmerPotato]

The 9995 executive dwarfs anything else on the board.  Geneve 2020 is now 2 full computers in one.

 

It's big

 

I like having two '138s decoding the chip enables (one for 2 memory enables, one for 3 CRU enables) because you can see physically what is going on.

 

For a tiny space savings, I could reduce the memory '138 and '04 to two '00 NAND gate chips.

 

I could replace the 128K flash (cheapest at $1.36, cheaper than 32K!) with a 28 pin EPROM. Blech.

 

I considered downsizing the extra 9901, but its I/O pins are essential.  Downsizing it to 9532 I/O expanders might actually take up more space! And CRU bit banging makes for very neat code.

 

I need additional logic if the 128K flash is to be re-programmable on-board.

 

So I consider losing the nice feature of the owner/builder being able to see the logic. I would replace the 3 chips with one square ATF22V10.

 

This PLD gives enough logic gates to add on-board programming of the 128K flash. You would use that to upload new boot firmware (bug fixes...) into the first 32K, and you could play with the FORTH prompt, write new diagnostics, and save the dictionary to one of the 32K Flash banks.

 

I'm considering that the 32K Flash banks would hold different 32K personalities. Think MDOS/GPL, FORTH, or UNIX. One of these is put into the DRAM at address 0 and becomes the first code that the 99105 runs (before it loads a full OS off the SD card.) Personalities would be selectable by holding down a key at power-on.

 

To recap, here's what the 9995 computer is responsible for:

• Booting first
• Waiting for the FPGA to initialize.
• Loading one of 3 boot personalities into the DRAM when the FPGA is ready (FPGA is the DRAM refresh controller.)
• Resetting the 99105 to kick off said personality
• Handling keyboard and mouse input
• And most importantly, running diagnostics on all the subsystems. This will be a powerful debugging tool for me.
• Receiving new Flash images on its serial port.
• Re-programming the 128K Flash 
• Re-programming the FPGA.
• Comforting the user at startup time.
• Blinking some lights.
• HexBus????

 

Overall I am liking the idea of losing the MSP430 and adding this standalone 9995. (It's essentially Stuart's Breadboard 9995.)

 

 

[+FarmerPotato]

1 hour ago, BeeryMiller said:

I took notice at something on your latest board.  Not knowing what kind of power is being fed onto the board, I have concerns about the heatsink area.  On the Geneve, there are multiple heatsinks and most everyone is aware of the scorched areas and damaged traces on the board.  Not knowing how much voltage regulation/power is going to be managed, I wonder if maybe standoff's from the main board onto a daughter board, new power supply cabling, or something needs to be considered to minimize potential heat damage to the main board and traces????

 

Again, just thinking out loud here as there may not be that much power being regulated to be of concern.

Thermal is something I need advice about. Can you elaborate on which parts of Geneves have cooked? I need to look at mine as I forget noticing heatsinks (the regulators?)

 

I can go by what I see others doing, or check the power consumption of each chip. 

 

The FPGA Cube will be fine, it is a 1.2 volt device internally with 3.3v I/O. It sips power. Nobody puts a heat sink on these. 

 

 

The 9995 and 99105, I don’t know. A 9918A we know requires a heat sink. Choose F18A to be safe! Or 9958.

 

The power supply will be an external brick giving 5V. Onboard will be TI modern  LDOs regulating 3.3 and 1.2 volts. I haven’t checked any RS232 analog bits yet to determine if it still needs 12V. 

 

I’m weak on knowledge of analog and thermal. 

 

I wonder if I should put in a tiny fan and a temperature sensor?

[+FarmerPotato]

ATF22V10 pins replacing logic chips and more on 9995 basic computer

 

Inputs 10 out of 12 available
CPUCLK
A0 for memory, LREX instruction
A1 for LREX
A2 for LREX
A8 for CRUEN
A9 for CRUEN
A15 for ODD/EVEN
DBIN for OE
PGM0 for Flash cmd/program mode
PGM1

PGM mode bits:
0 0 read mode
0 1 send command: even byte only
1 0 program even byte
1 1 program odd byte

Outputs 8 out of 10 available
CERAM*
CEROM*
OE*
!CRUCLK
PGM*
CRUEN0*  for 9901
CRUEN1*  for other 9901
CRUEN2*  for 9902

 

Checklist:

• Memory chips are driven and banked
• Programming is ensured
• CRU has enables and inverted clock
• LREX is masked from CRU

9901 inputs

CDONE  from FPGA
INTUART

 

9901 outputs
BANK0 select 32K of 128K flash
BANK1 
PGM0  program Flash
PGM1
NMI   to 99105
RESET to 99105
 

This is going to work out.

 

[+9640News]

18 minutes ago, FarmerPotato said:

Thermal is something I need advice about. Can you elaborate on which parts of Geneves have cooked? I need to look at mine as I forget noticing heatsinks (the regulators?)

 

 

The heatsinks/regulators closest to the LED (I think there are two), really cook.  I don't think the one by  VRAM is too bad.  Tim Tesch can probably tell you the frequency of the failure rate from his repairs or preventative maintenance.

Beery

[+9640News]

Another thought crossed my mind.

 

When Ron Walters designed the GenMOD/Memex setup, he had circuitry that would lock out memory pages to prevent cards that were not fully decoded from interfering with the memory.  This circuitry/logic was part of the daughter board that was soldered to the backside of the gate array.  I realize your memory is going to all be on the board, but not sure I am guessing you will still need to lock out various 8 blocks of memory if you plan on interfacing to PEBox's that could contain cards not fully decoded.

 

Beery

[Tornadoboy]

12 hours ago, FarmerPotato said:

2. It would be possible to add utilities to a DSR ROM, so that a CALL SPEED(0) for example could set FullSpeed mode, CALL SPEED(1) sets it back. I don't know how many speed levels there will be, except that speed will be finely calibrated for different modes TI-99/4A, Geneve, and something in between (modified TI-99/4A or 99/8 for instance.)

 

 

NICE!!

It'll be awesome to play around with all the glacier-paced basic and XB games and see how to tweak them to run perfectly, a lot of them would have had great potential if they hadn't been so bogged down! Games like Cavern Quest, Frazzle, Tick World and Meltdown immediately come to my mind! Now I'm really chomping at the bit to get one of these!

Edited September 4, 2019 by Tornadoboy

[+FarmerPotato]

1 hour ago, BeeryMiller said:

Another thought crossed my mind.

 

When Ron Walters designed the GenMOD/Memex setup, he had circuitry that would lock out memory pages to prevent cards that were not fully decoded from interfering with the memory.  This circuitry/logic was part of the daughter board that was soldered to the backside of the gate array.  I realize your memory is going to all be on the board, but not sure I am guessing you will still need to lock out various 8 blocks of memory if you plan on interfacing to PEBox's that could contain cards not fully decoded.

 

Beery

 

I guess you are referring to the top 3 address bits A,B,C that 4A cards are supposed to check are 0, but some don't? So they show up at >4000, >14000, etc.

 

Hmm.

 

I think that the address bus to the PBox will only be driven deliberately in GPL or a device driver, and that A,B,C will always be 0 then because there's no way for the console to drive them (only a Geneve card in the Pbox does that). In other words, the Pbox will look like a 4A Pbox. Memory accesses to anywhere in onboard RAM won't go out on the Pbox memory bus, so no interference, even if you leave your 32K card in there (this will be a real thing if you want to plug in JediMatt42's 32K and TIPI sidecar.)

 

I think the memory bank register needs another bit for "Pbox address" so that memory access to it goes out the Pbox port. For instance in GPL mode, the >4000 page has that bit set.

 

The cards that you have installed "in software" would prevent any Pbox access. For example, a "native" DSR will be found at >1000 emulating DSK1, WDS1 and so forth, and RS232 will be on-board at >1300 and >1500 (hmm, unless you really want more RS232?). 

 

But other than that, GPL would search device DSRs in the Pbox just like a 4A. If it were desirable to call a Pbox DSR under MDOS, the >4000 bank would have to be mapped in to correspond to Pbox address space, so leave a hole in your program memory map. Memory cards in the Pbox would be useless, but RAMDisks could be used, and I hope TIPI and HFDC.

 

RXB  mentioned the other day that people used DSRLNK that neglected to search GROM for DSRs. I think that it would be possible for GPLMODE to scan the loaded GROMs for DSRs. Then add stubs into the "native" DSR ROM, that pass control to GPL.

 

 

[+FarmerPotato]

2 hours ago, BeeryMiller said:

The heatsinks/regulators closest to the LED (I think there are two), really cook.  I don't think the one by  VRAM is too bad.  Tim Tesch can probably tell you the frequency of the failure rate from his repairs or preventative maintenance.

Beery

OK, good to know. Those regulators are stepping down the Pbox rails from unregulated 8V to 5V. I will be assuming a regulated 5V power brick, and the LDOs are there to filter out noise (or use efficient techiques to step it down) and don't dissipate large amounts of energy. The chips themselves still need to be measured.

 

 

 

[+mizapf]

Longer ago, I wondered why these regulators actually get so warm, unlike transformers that work with AC. The reason is simple: The regulators "burn" the excess power (voltage difference times current). If you have a current of 1A flowing through a 5V regulator, where you have 8V as input, it must produce 3W as thermal power to dissipate.

[HOME AUTOMATION]

I believe the LM78xx series uses a charge pump/capacitance scheme, so maybe slightly better!

[+InsaneMultitasker]

8 hours ago, BeeryMiller said:

The heatsinks/regulators closest to the LED (I think there are two), really cook.  I don't think the one by  VRAM is too bad.  Tim Tesch can probably tell you the frequency of the failure rate from his repairs or preventative maintenance.

Beery

On the Geneve, the three bottom regulators put out a lot of heat and will eventually fail if there is inadequate heat dissipation.  Fortunately, the capacitors are mounted to the side of the regulators, unlike the HFDC where the capacitors are mounted directly "above" the regulators, ensuring that they too will cook and fail over time.

 

I have seen more chip failures and burned boards when the heat sink compound is applied to the underside of the heat sink, which in turn transfers heat to the board via the mask/traces.

 

The V9938 regulator gets hot but rarely fails.

 

As some may recall the Heatwave Geneve has been operating 24x7 using switching regulators which output much less heat.  It cost about 40$ to retrofit a Geneve (regulators + capacitors) but so far has been well worth the investment.

[+FarmerPotato]

I found some basic information here:

 

How to monitor board temperature

http://www.ti.com/lit/an/snoaa26/snoaa26.pdf

 

A $1 chip that will do it:

http://www.ti.com/product/TMP1075

 

You might use one of these if you have a cooling fan with variable speed control.

 

I kinda doubt I will create a great amount of heat, but.

 

When I have a running board, I could take it to a trade show and ask the FLIR booth. They make infrared cameras for circuit board inspection, and always have a demo in the booth. That would show where the hot spots are. 

 

 

[+FarmerPotato]

On 9/4/2019 at 10:42 AM, BeeryMiller said:

Another thought crossed my mind.

 

When Ron Walters designed the GenMOD/Memex setup, he had circuitry that would lock out memory pages to prevent cards that were not fully decoded from interfering with the memory.  This circuitry/logic was part of the daughter board that was soldered to the backside of the gate array.  I realize your memory is going to all be on the board, but not sure I am guessing you will still need to lock out various 8 blocks of memory if you plan on interfacing to PEBox's that could contain cards not fully decoded.

 

Beery

 

I overlooked the possibility that you could have an alternate Pbox flex cable card driving A,B,C, maybe SGCPU.

 

The PBox Connection

I have two incompatible ideas on this.
 
1. I put a standard 4A card edge connector, and it only works with the flex cable or an exact workalike. Everything in the PBox works just like on a 4A. You could even plug in a JediMatt42 32K and TIPI. I bet people don't want to let go of their TIPI because it's so cool.

 

2. However, if I make modifications to the port, it won't work with TIPI, or TI's flex cable, would require a new Flex Interface card design, but it could add the A,B,C address lines. I don't see a lot of use for these.. do you really need a Geneve Memex card if you can put 32MB on the motherboard?

 

2A. It would be easy to just use a 40 pin IDE connector. It would fit directly to a TIPI (no 32K). Any PBox connection would use an adaptor.

 

A separate question is, can I use a nice round UltraATA cable instead of the bulky one?

 

I imagined a convenient round cable that doesn't fall out, and goes to a new type Flex Interface card in the PBox. Like this:

https://www.amazon.com/C2G-Cables-50033-Molded-Device/dp/B0002JFORI

 

Hmm, I can only find 2 foot cables of this type.

(it's a pity that a short card isn't safe enough against accidental pulls? A tall card costs a lot more money. A short card might rock and cause catastrophic shorts, right?)

 

Also, I repeat that I am a baby at analog and RF. I need help with cabling. I know it's a transmission line and what the textbook says to do. My brief experience is with expensive coax (ideal for transmission lines). 

 

We know that TI built the Flex Cable to be extremely robust to RF noise and signal degradation. And an IDE cable is not those things.

 

For these reasons, I think that many things are higher priority than working on the PBox option.
 

 

[+9640News]

43 minutes ago, FarmerPotato said:

 

 

2. However, if I make modifications to the port, it won't work with TIPI, or TI's flex cable, would require a new Flex Interface card design, but it could add the A,B,C address lines. I don't see a lot of use for these.. do you really need a Geneve Memex card if you can put 32MB on the motherboard?

 

The issue isn't dealing with the Geneve Memex as you would have the memory on your design with no Memex needs.  The issue is for the other cards requiring modification as they too would answer the bus memory paging if your plans were going to support a PEBox.  There are quite a few cards not fully decoded.

 

 

[+FarmerPotato]

3 hours ago, BeeryMiller said:

The issue isn't dealing with the Geneve Memex as you would have the memory on your design with no Memex needs.  The issue is for the other cards requiring modification as they too would answer the bus memory paging if your plans were going to support a PEBox.  There are quite a few cards not fully decoded.

 

 

I'm leaning toward option #1, standard 4A behavior in the PBox, no SGCPU or A,B,C driven. Avoid the issue.

 

It will work great as long as Geneve 2020 treats the PBox exactly as the 4A uses it. PBox will be in its own separate 64K address space, not mixed into the big 32MB. The PBox will not see ANY direct memory cycle for the DRAM, neither the first 64K of DRAM or big addresses wrapping around. Only stuff while GPL mode is active, and intentional access from MDOS (DSRs a la ROMPAGE. See below...
 

 

[+FarmerPotato]

Here's another long draft from what is shaping up to be the "Functional Specification of the Geneve 2020".

Addresses and Bank Registers

First. Definitions. Bridges out of The Cube (FPGA) are:

West Bridge:  99105 CPU connection bus (pins 1-36)
South Bridge: "Slow" 8-bit bus: VDP, speech, cartridge, PEB connector.
East Bridge:  IO ports (mouse, keyboard, SD, EEPROM, Stereo DAC, MIDI, everything else)
North Bridge: DRAM 24 bit address x 16-bit bus   (Note 7)

Bank Registers

 

Bank registers are essential because the 99105 still has 16 bit addresses and a 64K address space. To extend this to megabytes, the first 4 bits (3 in SAMS) pick out a bank register that extends the address to a physical address in the RAM. "Mapping" refers to loading a value into a bank register, which causes a Page to appear at that bank in 64K space. SAMS uses 8K pages, Geneve2020 uses 4K pages. It's easy to emulate 8K pages for SAMS. The 4A often uses 4K pages in cartridges and DSRs. 

DRAM has 2 SIMMs of 12 rows x 12 columns = 2^25 bytes. So 25 bit physical address. (you can install 2, 8 or 32 megabytes.) 

32MB (2^25) is divided into 8192 4K pages. 2MB would make 512 4K pages or 256 8K pages. (Note 6)

Bank registers point to 4K pages. 4K is 2^12. So bank registers must be 25-12 = 13 bits wide.

Additional bits in the bank register are: External, Protected (ROM), and maybe Fault-on-write.

Bank register (16 bits)

Bank register:   EFPx xxxx xxxx xxxx
99105 address:   .... ......... yyyy yyyy yyyy yyyy   (the 4 top yyyy determine the bank number)
Address (E=0):   0..x xxxx xxxx xxxx yyyy yyyy yyyy   (25 bit address, LSB irrelevant because 16 bit bus)
Address (E=1):   1... ......... xxxx yyyy yyyy yyyy   (16 bit address to PBox where usually xxxx=yyyy unless SAMS)

When E=0, the North Bridge activates, using the physical address to DRAM, 25 bits (LSB is ignored because 16 bit word)

      
When E=1, the South Bridge activates, putting a memory cycle to the address "xxxx yyyy yyyy yyyy" on the Pbox connector.

      
There will be special cases. For instance,  accessing VDP. In GPL mode, the >8000 bank is a special case. It must be decoded to the 4A memory mapped devices. It can be marked "E" so that the PBox does see the memory cycle. Meanwhile, in The Cube, >8000 can be intercepted because it is not really memory. Memory cycles will be sent to the South Bridge internal device AND the PBox. Memory read cycles must ignore the response from the PBox. This means you can write, but not read from PBox cards implementing VDP, GRAM, sound, or speech. Those functions are kept internal to chips on the Geneve 2020. Perhaps there could be a choice to go around this, I'm not sure.

GPL mode memory map of >8000

>8000-83ff PAD. 1K of BRAM (might as well add a full 1K) (there is 10Kbyte of BRAM in the FPGA) 
>8400 sound (extensively decoded by FORTI-2 synthesizer, MIDI)
>8800->8FFF VDP (decoded further) 
>9000->97ff Speech
>9800->9FFF GROM/GRAM

I verified that memory cycles do appear on the side port on the 4A, with the exception that with 16 bit accesses (ROM, PAD) you only see the top byte. Side port even reveals some of 9900 internal ALU cycles.

Using PBox from MDOS or other OS when not in GPL mode

All the values for bank registers if MDOS wants to access 64K in the PBox

>8000 pretend to access the 4A ROM space, but out in the PBox
>8002 Low RAM on the 32K card (but why?)
>8004 DSR space
>8006 Cartridge space (actually this is the on-board cartridge connector!)
>8008 Hmm, special memory mapped device page
>800A High RAM on the 32K card (but why?)

If you want to read/write to the PBox in MDOS, your program needs to set a bank register of your choice to one of the "E=1 ????" 64K external space addresses. So, you could map the >4000 space into >C000 if you like by setting bank register for >C000 to >8004.

 
Nothing prevents you from mapping in that special GPL mode page for >8000 in MDOS. But you don't need it. Geneve 9640/MDOS memory mapped devices will be emulated by defining another special page... It could be any unused external address.

In GPL mode, the bank register for >8000 will be loaded with "E=1 page 8", or >8008, corresponding to External address >8000. (Bank >9000 will have >8009.)

In native mode, you COULD set any bank register to "E=1 >008" to bring in the 4A special page and use it as you please.

How to set up Bank Registers to achieve GPL mode

Assume a chunk of DRAM >10000 - >1FFFF is being used (this would be chosen dynamically from free pages.)

Remember, pages are 4K each. The first digit: 8 means External, 2 means read-only.

0 >2010 first page from >10000, holding the 99/4A ROM
1 >2011 second free page at >11000
2 >0012 Low RAM
3 >0013 Low RAM
4 >2014 For on-Board read-only DSR from CRUBASE >1000 usually. (Note 1)
5 >2015 like the above except 5 instead of 4. (Note 2)
6 >8006 for a physical cartridge. >2016 for a cartridge ROM image. (Note 3)
7 >8007 Ditto. >0017 for MiniMem 4k RAM.
8 >8008 The aforementioned intercepted memory-mapped devices
9 >8009 Ditto
A >001A High RAM. (Note 4)
B >001B 
C >001C
D >001D
E >001E
F >001F

Notes

1. Magic happens when you SBO 1 at other CRU bases. >1100 gets you >8004.
2. Any bank switching or memory map scheme is done in original hardware.. Disk Controller and RS232 have memory mapped devices in >5000, which just work. 
3. Magic happens when you bank switch on an image. There has to be more memory all ready.
4. Unless you REALLY want to use external PBox 32K, in which case set this to >801A to demonstrate how slow it is. Or if your RAMdisk uses that scheme...
5. Heck, multiple GPL environments could be in memory simultaneously, they would just get different free pages.
6. Oh shit. The Geneve 9640 has 8K pages and I need the bank registers to "just work". Maybe full 32MB native access uses a unique way to load its own 16 bit bank register, and the old way to load a 8-bit Geneve 9640 bank register, and magic happens to square them away.
7. The directions are now Chinese--East Bridge became up on the map. North and South bridge matches PC terminology. I am not saying "the directions are in Chinese." The directions will be in techspeak.

 

Magic = Verilog code that causes exceptions to the rule in weird corner cases.

 

[+FarmerPotato]

Extended Memory Mapping in 99105

The 99105 can extend the 64K address of instructions in various ways. This can be doable in the North Bridge--it will be really cool, and  just more Verilog programming.

 

The 99105 was designed to offer 3 extended memory schemes (see page 17 of 99000 manual.)

 

 

1. Memory Paging. A separate 64K address space. Code is executed from this space to handle Interrupts, XOPs, and some CRU (Note 8.)  We'll call this the "Supervisor" space. An interrupt or XOP handler in this space can use LDD and LDS to look back at the "user" space memory. When you think of the XOP as an operating system call, it makes total sense for it to execute code and see data that the "user" program can't see or mess with.

 

2. Segmentation. One 64K for instructions, one 64K for data. If used, PSEL extends the bank number, so there are 16 more banks for data. This is unfamiliar to 99/4A programmers (but standard in bigger computers). You would use the forbidden DSEG around your BSS and other data, and PSEG around your code, and the object code LOADer would have to handle those tags. See, it's already supported in your assembler  (I think not the loaders)

 

3. Bank Registers (LS610 external memory mapper). What SAMS coders are familiar with, and the scheme discussed so far.

 

The intention of the 99105 designer was that scheme 1 overrides scheme 3. The benefit of this is that a user program can use the >0000 address space for anything, while RESET, interrupts, or XOP flip to the other 64K address space. On the Geneve, addresses >0000 to >0400 (?) are reserved for the implementation of interrupts and XOPs.

 

In Geneve 2020, the bank registers would be ignored during an XOP.  This means that pages 0-15 of RAM (the first 64K) are reserved as "Supervisor" space by the operating system. This is a good thing. The executive (little brother 9995 board) would push the "personality" 32K image into this RAM space at boot time.

 

4. Memory Map. There is another scheme seen on the 990 external memory mapper, which separates the 64K into three zones, but I don't think that is wanted here. It's essentially a 3 bank register scheme for carving the 64K into supervisor, user, and data spaces at any 16-word boundary (not 4K pages) that map into some large physical memory addresses. See Load Memory Map instruction on the 990.

 

Conclusion

 

Using these features of the 99105 will make for more elegant programming and a more powerful computer. However, it will take careful thought not to break compatibility with MDOS which assumes scheme 3. I think MDOS would require boring modifications to make the XOPs compatible, but user programs that follow MDOS standards would work without changes. (Note 9)

 

Notes

 

8. CRU address space above >1C00 is considered privileged in the 99105. If user code tries to access it, there is a Level 2 interrupt. This handler could simply examine the address and permit the access up to >1FFFE. Compatibility is preserved. Devices above this zone could be privileged low-level things. Including the bank registers themselves, and low level I2C access to system devices (if you mess with them, you could freeze out your keyboard, or cause havoc in other ways.) Serial device access would not be privileged, because terminal programs expect to blaze ahead with direct access. 

 

9. It's becoming apparent that MDOS will need modifications for Supervisor mode and maybe all page management. This could be a big deal. But it's a significant benefit to offer memory space that is protected from being trashed by buggy user programs. Imagine if buggy user programs could never lock up the computer or crash the OS again.

 

 

 

[+InsaneMultitasker]

Memory from 0000-0400 is reserved for both XOP/interrupt vectors and for task-related information used by OS and any launched/forked tasks.  Keep in mind that many (most?) applications manage their own pages directly based on a pagelist that is provided by the OS and applicable XOPs and mapped by the programmer. 

[+9640News]

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