CoCo2 64K and SAM

[Van]

So I've been digging into hardware docs and I'm not clear on a few points. Looking over the 4 RAM/ROM SAM modes for CoCo2s; the lower 32K is always there, and the ROM is banked into the the upper 32K by default (?). So with a ROM PAK you are only going to see 32K RAM unless you switch modes.

I'm confused as to the cartridge 16K, with the ROM mapped in, could you write to a address mapped into the the 'PAK' $C000-$FEFF address space? I was thinking of a NVRAM Module or a Flash chip on an ROM PAK. It seems straightforward, or is there something I'm overlooking?

Yogi

Edited July 12, 2015 by Van

[JamesD]

I don't think anything in the SAM restricts the ROM area to read only.

Reads and Writes are controlled through a single line.

[Van]

I don't think anything in the SAM restricts the ROM area to read only.

Reads and Writes are controlled through a single line.

Well yes R/W of course. Must have mis read something about reads being directed to ROM and writes switching mode to RAM or something to that effect. But like I said I'm a little confused

From Robert on the CoCo list archive:

"The normal state of a Coco2 is Map Type 0 + Page 0. That puts RAM from

0-$7FFF and ROM from $8000-$FFFF. Map Type 0 + Page 1 keeps ROM from

$8000-$FFFF but swaps the lower RAM (if you have 64K RAM) from the lower

half to the upper half.

So, there are two switchable banks of 32K RAM.

Map Type 1 ( all RAM mode) deactivates paging and the latch at $FFD4/$FFD5

is inactive."

Not sure what is Page 0 & 1 (is this the 2 32K pages of RAM?) but seems clear enough in regards to the cartridge space.

 

[JamesD]

If I remember right...

Lower RAM is always RAM, the banking only switches between upper ROM and upper RAM.

The cartridge is mapped to the same 32K bank as ROM.

[JamesD]

I haven't looked at the CoCo cart interface in a long time so I'm not 100% sure on functionality.

This signals you have to worry about on the expansion connector are listed on page 42 of the Technical Reference manual.

 

The key ones dealing with address decoding are:

CART - tells the system you have inserted a cartridge so it will execute the ROM

SLENB - Input to disable device selection. External address decoding can disable internal devices. You could replace the internal ROMs for example.

CTS - Cartridge Select Signal. I believe this is the SAM signal indicating cartridge ROM space is being accessed (32K ROM bank)

SCS - Spare Select Signal - Mapped to the $FF40-$FF5F address range. I believe the floppy controller uses the first half but you could simplify address decoding of hardware registers with it.

Edited July 12, 2015 by JamesD

[Van]

Thanks JamesD, yea been going through lots of docs and sometimes it's 'information overload' and I need a sanity check. I must be confusing something I read about the 3's GIME operation.

Testing out my EPROM cart board and had the thought of using DIP Flash or a NVRAM on it somewhat like Cloud9's miniFlash. Of course the banking control would have to be off board because of size restrictions (Eagle Free's brd size limit) unless I go to SMT (in which case I would just get a miniFlash). Anyway, there doesn't seem to be a conflict to doing Writes to the ROM PAK space, but will knock together a proof of concept.

Thanks again,

Yogi

[Mr SQL]

The CoCo3 uses the all RAM mode by default, the BASIC is copied from ROM and patched with Microware's revisions.

 

Will be interesting to see the results of your experiment,

[Van]

Hi MrSQL,

I ordered a couple AT29C512s from Hong Kong so a few weeks wait, but finding 5V DIP devices is getting harder and harder.

I think it should be an easy mod to my test board, the Flash is almost a direct drop-in. Of the extra 4 pins on the 32p package, 2 are un-used, and the other 2- p32 is Vcc ( p30, which lines up with p28 on the EPROM, is a NC) and p31 is /WE; the other 28 (27) pins are one for one with the EPROM's. so just adding the /WE and a jumper to Vcc.

The most complicated change is adding a NOR gate to invert R/W (for the /OE) and for gating R/W to the /WE ( to memory protect Flash writes).

For testing, I can just use the on-board jumpers to do the bank selection, but later will add the hardware for a miniFlash like FBSRegister to my external board/s (already has ADR decoding on them) for software control. I don't know the Flash device that is used on the C9 board but if it has similar timing/programming algorithm, might be good to go for the software. Fingers crossed

If it works out, will add the changes to the PCB design so it will be compatible with either EPROMs or Flash. Of course in stand-alone use, all the bank control will be manual jumpers so it wouldn't be as nice as the miniFlash card but will be DIY friendly and fit in nicely with my bigger project.

Yogi

[linville]

The SAM datasheet makes it look like you can write to the $C000 range (decoded through the CTS line) , but IIRC empirical results showed otherwise. OTOH, I had a discussion with a Dragon user that swore he had done just that with an SRAM fitted in a ROM cartridge.

 

So, YMMV -- I am eager to hear about your results! :-)

[Van]

The SAM datasheet makes it look like you can write to the $C000 range (decoded through the CTS line) , but IIRC empirical results showed otherwise. OTOH, I had a discussion with a Dragon user that swore he had done just that with an SRAM fitted in a ROM cartridge.

 

So, YMMV -- I am eager to hear about your results! :-)

After more research I'm very confident that there aren't any road blocks. Reading the miniFlash manual, there doesn't seem to be any major hoops to the Flashing algorithm; but haven't looked at the source. Don't know for sure the HDL in the CPLD, but if there was a sector sized 'write' port mapped to a ram area for Flashing. I would think it would be have to be noted to avoid addressing conflicts.

At any rate, got my AT29C512 flash chips in from HK (very fast shipping this time!) so will have a prototype to mess with soon. May setup a RAM chip first for proof of concept, before working on the Flash driver.

Yogi

[JamesD]

After more research I'm very confident that there aren't any road blocks. Reading the miniFlash manual, there doesn't seem to be any major hoops to the Flashing algorithm; but haven't looked at the source. Don't know for sure the HDL in the CPLD, but if there was a sector sized 'write' port mapped to a ram area for Flashing. I would think it would be have to be noted to avoid addressing conflicts.

At any rate, got my AT29C512 flash chips in from HK (very fast shipping this time!) so will have a prototype to mess with soon. May setup a RAM chip first for proof of concept, before working on the Flash driver.

Yogi

Make a RAM board that responds above the DOS ROM (CoCo 1/2) I'm sure someone might find a use for it.

Edited July 23, 2015 by JamesD

[Van]

OK, so I mounted a 43256 32Kx8 SRAM on my proto cart and I can confirm that at least on my CoCo2, reads and writes to the /CTS window works fine.

Without the cart installed, reads return $FF regardless of the value Poked.

My quick an dirty test code

10 for x=0 to 255
20 z=49152+x
30 poke z,x
40 next x
100 for x=0 to 255
110 z=49152+x
120 a= peek(z)
130 print a
140 next x

I'll post some pixs and the schema ASAP.

@ JamesD I could mod the BRD for a 128K (or larger?) bank switching cart. The simplest would be 8 - 16K banks but with more logic smaller banks could be used. Any thoughts? Of course without some Basic or DOS wedges it would only be useful in ML but that's not a bad thing.

Yogi

[JamesD]

I suppose it could be used for a RAM disk if it's 8K. It could also be 1/2 ROM (Flash) and 1/2 RAM if there's room.
Since it should also work with the POKE 65495,0 high speed mode, that would offer new CoCo 1/2 programs a little more speed.
8K is enough for a hi-res screen + 2K for program data.
When combined with the high speed mode it should allow faster line drawing and more sprites moving around per frame.
In theory anyway.

*edit*
You could also patch older games to put the direct page in that RAM and enable the high speed mode if they run a little sluggish.

Edited July 23, 2015 by JamesD

[Van]

I suppose it could be used for a RAM disk if it's 8K. It could also be 1/2 ROM (Flash) and 1/2 RAM if there's room.

Since it should also work with the POKE 65495,0 high speed mode, that would offer new CoCo 1/2 programs a little more speed.

8K is enough for a hi-res screen + 2K for program data.

When combined with the high speed mode it should allow faster line drawing and more sprites moving around per frame.

In theory anyway.

 

*edit*

You could also patch older games to put the direct page in that RAM and enable the high speed mode if they run a little sluggish.

Well a combo Ram/Flash is doable. I've built a kind of piggyback design way back in my MCS 8052 days, with a SMD 62256 in the middle of a 28 Pin DIP footprint. The EPROM socketed above and the SRAM on the board, banking in one or the other. The biggest problem is finding DIP Flash devices, the industry has moved on. The AT flash chips I found on ebay are NOS and the only other source was Futurlec I think. So some are still out there but no telling how long.

Although, I'm partial to a battery backed RAM design, no complicated Flash routine in addition to the added code of the banking control. With an 8 pin NVRAM controller you get ~99% of the reliability of a Flash with the ease of RAM. The downside is the cost of the controller, $10 for a DS1218 from Digikey so combined with a 512Kx8 RAM and the support logic, parts cost is around $20 + board cost. Of course a builder could elect for just the SRAM to cut the cost.

Could you describe the High Speed mode a bit more, I'm really veage on my understanding. I thought going to HS would mess up the VDG timing and the screen.

Yogi

[JamesD]

There are two high speed modes on the CoCo 1/2. Only POKE 65497,0 disables the video refresh.
I can't guarantee the SAM won't choke with the other one if you put video in the ROM address area since I'm not sure it's been tried before.

[Van]

There are two high speed modes on the CoCo 1/2. Only POKE 65497,0 disables the video refresh.

I can't guarantee the SAM won't choke with the other one if you put video in the ROM address area since I'm not sure it's been tried before.

Thanks, I'll have to do some research. I do recall something about the speed poke for running rom code with the side effect of a garbled screen. For my own uses I could live without a display for music play. The speed up doesn't corrupt the DRAM does it?

Static RAM shouldn't care as long as it's fast enough for the shortened machine cycle, the device I'm looking at has 55nS access.

I'm a bit surprised that I seem to be treading 'new ground', seems like RAM disks and expansions have been around for ever. It's a little strange to me that the CoCo was/is a bit overlooked; with Radio Shack and the association as a DIY business. I mean, for me, RS fueled my interest in electronics. The booklets by Forest Mims and the array of parts on hand got me started; good times.

Yogi

[linville]

I have at least one RAM disk pak from "back in the day", but I'm not sure how it worked. I wouldn't be surprised if it was actually using an I/O address as a write window, but I really don't know.

The video accesses are responsible for the DRAM refresh. I'm not sure what the effect of pointing the video buffer into the$C000 range would have on that -- more research required! :-)

[JamesD]

This is actually something I was considering trying to get more performance from 3D wireframe animation.
Drawing lines requires a lot of video RAM access. I wanted faster line drawing than I was able to achieve on the MC-10.
Actually, being able to double buffer the video (requires 12K) was more to my liking though so there is a bit of a problem there.

The SAM has no issue displaying video from the ROM area, it's just a question of what happens with the high speed enabled and how many extra cycles can we gain if it does work.

It would be nice if BASIC could be patched to place it's video in that area too. It would free up several K for BASIC programs. I really could have used that as a kid.

[Van]

So I couldn't see how to edit my first post; this will have to do

Here is my proto cart with a SRAM

.

https://www.dropbox.com/sc/lnb0zrptyp43ws4/AAA5IEIwnjS6sApMGQ7MaihWa

The two pairs of jumper on the top of the pix control banking for A14 and A15. The Right set selects the source, local or external (40 pin header). the Left set selects the logic level for A14 and A15 in local mode.

The bottom jumper block selects the /CS source, local-/CTS from CoCo or Ext-from 40 pin header.

The dead bug is a 74HCT00 NAND, 2 gates are used. the first gate inverts R/W and it's output drives /OE and one input of the second gate. The second gate allows for a software controlled Write Protect. The second input is lightly pulled high with a 10K R so an external circuit would pull to GND to block Writes to the chip.

The 32K SRAM is pretty much a drop in for the 27Cxxx EPROM foot print but note the blue jumper to pin 27, /WE. as stated above, this is controlled by the NAND /WP.

There is also a Red Vcc jumper unused here, but needed for the larger AT29C512 Flash, 32 pins. The 40 pin header is a mirror of the card edge signals with a few pin re-used for added control: 1- E A14, 2 E A15, 34-E CS.

This board has already been redesigned to accommodate either a 28 pin EPROM or a 32 pin Flash, but am considering changes to also allow SRAMs.

Yogi

[Van]

This is actually something I was considering trying to get more performance from 3D wireframe animation.

Drawing lines requires a lot of video RAM access. I wanted faster line drawing than I was able to achieve on the MC-10.

Actually, being able to double buffer the video (requires 12K) was more to my liking though so there is a bit of a problem there.

 

The SAM has no issue displaying video from the ROM area, it's just a question of what happens with the high speed enabled and how many extra cycles can we gain if it does work.

 

It would be nice if BASIC could be patched to place it's video in that area too. It would free up several K for BASIC programs. I really could have used that as a kid.

Along this line, I built up a cart with a 512Kx8 SRAM and a Bankswitch Register mapped to $FF59 (following the choice used with the miniFlash brd). The add-on circuit has provisions for a NVRAM controller (DS1210 but I need to get a bat holder to test this) and jumpers to configure the board for a Flash or SRAM.

I've run a few simple Basic tests, filling pages on different banks and reading back, both at normal speed and using the split speed poke. It seems to work fine and there is a noticeable speed up, but I'm just judging subjectively.

Any ML programmers out there that can point me to a simple routine, block move or something like that, that I can run from the $C0xx space? ATM I don't have a toolchain setup so some advice on a cross compiler/assembler would be welcome, I've been looking at the Toolshed and LW Tool chain, opinions?

 

Yogi

[Van]

 

Sorry Dub post

Edited August 1, 2015 by Van

[Van]

ARRRRG, must be having a short-bus moment. Double posted and trying to fix that, deleted my whole post.

Anyway, built a 512K SRAM cart on one of my first run cart boards; has provisions to configuration it for 32pin SRAM with a NVRAM controller or 39F Flash devices. Bankswitching register is mapped to $FF59 (as per the miniFlash) and provides a software controlled Write Protect bit.

Been doing simple tests, loading pages to the banks and reading out. Works well with both the default speed and the split-speed poke. There is a noticeable speed up but I'm just judging by 'by eye'.

I've got to get on-line with a ML toolchain for a better test routine. \

Yogi

[Van]

So I did a timed test of using the SRAM with this code:

 

 

10 REM /CTS MEMORY TEST

20 REM

100 BR=&HFF59:PAK=&HC000:RW=&H80

105 REM BR-ADR OF BANKSWITCH REG

107 REM PAK-ADR OF /CTS BASE , RW-WRITE PROTECT BIT 7

120 POKE 65495,0 : REM SPLIT SPEED

130 BANK=0: POKE BR,BANK+RW : REM SET BANK AND WP BIT 7

140 PRINT BANK

150 FOR X=0 TO 255 : REM LOOP TO LOAD 256 BYTES IN BANK 0

160 POKE PAK+X,X

170 NEXT X

180 PRINT"LOADED 256 BYTES"

200 FOR BANK=1 TO 31 : REM LOOP THRU BANKS 1 TO 31

220 FOR X=0 TO 255 : REM READ/WRITE LOOP

230 POKE BR,0 : REM SWITCH TO DATA BANK 0

240 D=PEEK(PAK+X) : REM READ FROM BANK 0

250 POKE BR,BANK+RW : REM SWITCH TO CURRENT BANK AND ALLOW WRITES

260 POKE PAK+X,D : REM SAVE DATA INTO CURRENT BANK

270 NEXT X

280 PRINT "BANK 0 MOVED TO" BANK

290 NEXT BANK

300 POKE 65494,0 : REM BACK TO DEFAULT SPEED

310 END

 

Without the Split Speed poke: 2min 24sec

with the poke: 1min 44sec

For what it's worth,

Yogi

[JamesD]

So I did a timed test of using the SRAM with this code:

 

 

Without the Split Speed poke: 2min 24sec

with the poke: 1min 44sec

For what it's worth,

Yogi

Just remember that we already know ROM can run with that POKE so any BASIC test program will run faster than without the POKE.

You need to compare standard RAM vs your expanded RAM, both with high speed enabled.

[Van]

Just remember that we already know ROM can run with that POKE so any BASIC test program will run faster than without the POKE.

You need to compare standard RAM vs your expanded RAM, both with high speed enabled.

Yes I agree, but I'll have to do some research on setting up a better test. Perhaps something like the test I posted but a version that loads and copies only to DRAM? I'm not sure on the Tandy but would I need to lower RAMTOP (or the ECB equivalent) and then do reads and writes to the DRAM above this for a baseline? Of course the Basic prg would still be in slower DRAM.

Yogi