16-Bit RAM and the RF Shield...

[Tursi]

15 minutes ago, DuaneAL said:

Is the scratchpad limited to 256?  I seem to recall that it could be expanded but I don't know if there would be a benefit to doing that.  Although, if you had a larger scratchpad, that might make Playground more interesting.

The scratchpad responds to memory addresses >8000 to >83FF, so you could in theory drop 1k of RAM there. Any software that relies on the mirroring would fail, but in the unlikely instance that any was found, we could fix it.

 

[JB]

I would swear I saw instructions to modify the system for 1kB of scratchpad once, but I'm unable to find them.

[Reciprocating Bill]

Here are more accurate numbers for the BYTE Sieve in 9900 assembly. The previous stock numbers did not reflect my most efficient 9900 code, omitting one tweak. The following reflect identical code on a 16-bit console, on a stock console using scratchpad for registers (expansion ram for code and the ~8190 byte array), and a stock console using expansion RAM for everything. 

 

16-bit              Registers in PAD                     Nothing in PAD     

6.41"                 9.19"    70%                 12.00"     53% of 16-bit

 

Just for context, the original BYTE article cites assembly speeds of 6.8" for a Z80 at 4 Mhz (presumably), 13.9" for a 6502 at ~1 Mhz (Ohio Superboard), 4" for an 8088 at 5 Mhz, 1.9" for an 8086 at 8 Mhz, and 0.49" for an 8 Mhz 68000. Time (and memory address space) was already marching on.            

 

[+DuaneAL]

7 hours ago, Tursi said:

The scratchpad responds to memory addresses >8000 to >83FF, so you could in theory drop 1k of RAM there. Any software that relies on the mirroring would fail, but in the unlikely instance that any was found, we could fix it.

 

Thank you!

[apersson850]

A limiting factor for the expansion of the scratch pad is that the range >8000 - >9FFF is also used to map in other stuff. Like video and sound processors.

But the first 1 K is free. As already written above, the existing 256 bytes show up four times in that range. Thus the byte at addresses >8000, >8100, >8200 and >8300 is actually the one and same. An expansion will further decode this, so you get four different 256 byte segments here.

My 16-bit memory expansion design allows paging in memory into all 8 K slots in the machine, >8000 - >9FFF included. But as soon as I do that, it will cover everything in that range. Thus I can't access the VDP when I have memory there.

In addition to the RAM PAD, access ports to video, sound, speech and GROM are located in the >8000 - >9FFF range.

[+mizapf]

I used the area below 8300 in the Geneve's GPL mode for my Guru meditation program:

 

 

[Kchula-Rrit]

Like this?

 

I had heard of some unused bits in the 9901.  If the two RAM chips were replaced with 512-byte chips, a dual 2-to-1 multiplexer could be used to switch between actually using A6 and A7 to address the full 1K RAM or keeping the new RAM in the >83XX range.  If the 9901 initialized to all inputs the pull-up would keep the RAM TI-compatible until software enables the whole bank.  The formerly-unused bit being set high would keep TI compatibility (mirroring), and a low would enable the whole >8000-83FF range.

 

A 74LS157 could be "dead-bug" glued (they called it that when I worked on computers for a living) to the top of another chip to tap the signals.

 

Apologies in advance if the picture messes things up, the Web-site seems to not let me insert it where I want to.

 

K-R.

On 11/3/2020 at 6:00 PM, Tursi said:

The scratchpad responds to memory addresses >8000 to >83FF, so you could in theory drop 1k of RAM there. Any software that relies on the mirroring would fail, but in the unlikely instance that any was found, we could fix it.

 

 

Edited November 12, 2020 by Kchula-Rrit

[Tursi]

Be aware that the HIGH output on a 9901 is not high enough voltage on it's own to be a stable logic level to a RAM chip... I tried that years ago.

 

(Edit: I see you do have a pull up there, so might work!  )

 

Edited November 12, 2020 by Tursi

[apersson850]

For my design, where I can overlap RAM over everything, I added a separate 74LS259 latch to get eight bank enable signals.

[Kchula-Rrit]

21 hours ago, Tursi said:

Be aware that the HIGH output on a 9901 is not high enough voltage on it's own to be a stable logic level to a RAM chip... I tried that years ago.

 

(Edit: I see you do have a pull up there, so might work!  )

 

I put the pull-up there because the 9901, upon reset, is set to all pins being inputs.  This would make the default setting to TI compatible, with RAM at >8300-83FF.

 

The 9901 data sheet, along with the TI 99/4A schematic, use 10K pull-ups instead of the 1K I used.  The data sheet said the input current on 9901 inputs is in the micro-amps range.  It did not say what the output max current is, but the 99/4A uses 9901 outputs to drive TTL chips.

 

Anyway, looking at the schematic, Pin 29 (P10/INT12), Pin 37 (P1), and Pin 38 (P0) appear to be unused.  Pin 29 even has a 10K pull-up already on it.

 

K-R.

[HOME AUTOMATION]

I've had a console where a lockup occurs before cassette prompts if (P10) is not held high!

[Reciprocating Bill]

I eventually opted to upgrade a second known good board (tested for several days before upgrading) and find it 100% stable and reliable. Looking for another pure assembler project as a benchmark, I landed on the N-Queens puzzle (how many ways are there to place N queens on an NxN chessboard with no queens attacking one another?). It displays a board, uses sprites to represent queens arrayed in successful positions and displays a count of the solutions found, so VDP access is very moderate. It finds and displays 92 correct 8x8 positions in 1-2 seconds, 724 10x10 positions in 26.6 seconds and 14,200 12x12 positions in 11 minutes, 16 seconds (combinatorial explosion and all). A stock console runs the 10x10 routine (registers in scratchpad) in 37.5 seconds. So the stock console runs at 71% of the speed of the upgraded console - or, put another way, the upgraded console is ~1.4 times faster than stock in this instance. 

 

[Reciprocating Bill]

Putting this in perspective, I found online a letter written in 1973 (By Edward Reingold at the University of Illinois at Urbana) giving a first report of the number of solutions for 14x14 and 15x15 N queen puzzles.

 

The 15x15 puzzle was solved on an IBM 360/75 in 160 minutes (He remarks, "I have no idea where the student got the money"). NASA used four of these during Apollo. I wouldn't attempt that on the TI, but running an interpreted BASIC on my 2012 MacBook Pro (Chipmunk BASIC, on which all variables are floating point) I get all 2,279,184 15x15 solutions in 35 minutes.

 

The point being: sometimes we (or at least I ) don't appreciate what we have, computationally, these days. 

Edited December 5, 2020 by Reciprocating Bill

[Kchula-Rrit]

I drew up a schematic for a 16-bit RAM that would include a bank at >6000-7FFF to fill the GROM hole, and to include a 16-bit DSR in RAM for a device I'm thinking of adding.  Thierry Nouspikel's EEPROM Web page gave me even more delusions of grandeur, so I'm thinking of changing the schematic for DSR EEPROMs.

 

30 years ago I tried adding a memory expansion, which killed the console I put it in.  Now that I have proper test equipment I'm going to try to resuscitate that console and use it as a test-bed for the new memory.  I tried to put the CPU chip in a socket, so I could move it to a daughter-board, along with the new RAM.

 

I'm really sure the daughter-board won't fit under the clamshells; just won't run it when the Better Half wants to watch Star Trek.

 

K-R.

 

[apersson850]

From my own experience, I can recommend doing what I did. Install 64 K RAM and make it pageable with CRU bits. You can set it up so the 32 K RAM is available on startup, but the other 32 K is not. Then you can page in 8 K chunks to cover the ROM, the "GROM hole" or whatever. With correctly written software, you can have 64 K contiguous RAM in the machine. You have to disable to access the VDP and such stuff, but the RAM will still retain the content. Thus you can have a large data buffer for something in such segments.

Disable the 32 K RAM parts and the standard 32 K RAM expansion becomes accessible. This gives any console with this modification, when connected to a "standard" expansion system, two pages of 32 K RAM expansion to play with.

Since the easiest way to install 32 K RAM is by two 32 K RAM chips anyway, this isn't very tricky. There are several modifications that install 64 K, but only use half of it.

[Kchula-Rrit]

Right now, I'm mulling my options.  Originally, I was thinking I could use one of the 74610s I bought years ago to make mappable RAM, but discarded the idea for some reason.  I think the reason was, I wanted a smaller page-size than 4Kbytes.  At the time I was working on systems that used a 512-byte (1 disk sector) page-size.  Now, I'm not convinced it would be a problem.

 

My most recent idea was to put 1MB RAM in the GROM-hole, and use a 74259 to select 8K pages using the high 6 bits of address.  A 74251 would allow me to read the "map" through the CRU.

 

I'm back to considering the 74610 idea again.  If I recall correctly, it takes the top four address bits and maps it to a twelve bit page value, so the address is 20 bits.  Since the TI does not use the LS (odd/even) bit I could squeeze another bit out the scheme to get 2MB.  Of course the software would have to take that into account.  It also has a "bypass" mode that could used on start-up.  After that, I could map Page 0 to the console memory space to use the VDP and other peripherals.

 

Only problem is, the 74610 would use RAM space to access it.  I suppose I could use the CRU to read and write the map registers (more 74259s!).

 

Of course, I'll try it on a breadboard first, to make sure it works.

 

I must be channelling Professor Fate...

 

K-R.

[apersson850]

OK. My design doesn't map different memory into the same address. It just installs RAM across the entire address range, then makes it possible to enable/disable RAM in 8 K chunks. With RAM disabled whatever is "below" shows up. It doesn't matter if that's console ROM, devices like the VDP or the standard memory expansion.

Edited December 10, 2020 by apersson850

[+TheBF]

On 12/5/2020 at 11:31 AM, Reciprocating Bill said:

Putting this in perspective, I found online a letter written in 1973 (By Edward Reingold at the University of Illinois at Urbana) giving a first report of the number of solutions for 14x14 and 15x15 N queen puzzles.

 

The 15x15 puzzle was solved on an IBM 360/75 in 160 minutes (He remarks, "I have no idea where the student got the money"). NASA used four of these during Apollo. I wouldn't attempt that on the TI, but running an interpreted BASIC on my 2012 MacBook Pro (Chipmunk BASIC, on which all variables are floating point) I get all 2,279,184 15x15 solutions in 35 minutes.

 

The point being: sometimes we (or at least I ) don't appreciate what we have, computationally, these days. 

Can we safely assume (or do we know) that the 360 was running a compiled program?  (Fortran maybe?)

 

[Reciprocating Bill]

On 12/10/2020 at 11:49 AM, TheBF said:

Can we safely assume (or do we know) that the 360 was running a compiled program?  (Fortran maybe?)

 

The letter doesn't say. But given the apparent expense of CPU time, I think that assumption is safe. 

Letter vis queens.pdf