1090XL remake

[_The Doctor__]

did you try the X Com wedge, or the ANTIC Disks demo etc

[reifsnyderb]

9 minutes ago, _The Doctor__ said:

did you try the X Com wedge, or the ANTIC Disks demo etc

I did not.  I've been using XRAM0220, SimCheck-1.5, SimTest-0.8, SysInfo 2.24, and SpartaDOS X.  Tonight is the first time I tried POP and was surprised it works of of my 16k 600XL with the 1090 repro board and the new 320k 1090 card. 

 

It is pretty neat to see POP.  I remember playing POP on a PC.  At the end of the first level you had to drink the right bottle to get to the next level.  I spent an evening making a chart of which bottles were good and which were bad so I could play the game.   🙂

 

[drac030]

If SDX did not sense any extension, it would not hang, it would just default to plain 64k configuration. So it seems that it does detect something, but the extension does not work correctly.

 

I of course have no idea why it does not work, but there are two things to mention, perhaps:

 

1) SDX scans the extended RAM not bank by bank, but in portions 64k (= 4 banks) each. The bits 2-3 of PORTB are held %00 during the scan, the remaining 4 bits get flipped. The premise is that if there is a RAM extension at all, it would consist of an integer multiple of 4 banks.

 

2) SDX tries to select the last banks first to load itself, leaving the 130XE-compatible banks free as long as it is possible (e.g. on a 320k RAMBO extension, SPARTA.SYS will be loaded to bank PORTB=$8F). So, if other programs work, but SDX does not, this may mean that out of the entire extension the last 64k is not functional.

 

The mask (PBMASK) you found in the manual is of informational purpose only, its content gets setup automatically during bootup (along with other such parameters, line the number of banks etc.)

 

EDIT: you can of course force the SDX to ignore the extension and use the 64k configuration. To do that, format a diskette (or ATR or whatever medium you use for D1) in SpartaDOS format, save a custom CONFIG.SYS file to its main directory, then bootup from there. Once you get to the DOS prompt, MEM /X will tell you how many banks the system can see. Also you can do PEEK COMTAB+$1C to see what is the extension mask.

 

To make a custom CONFIG.SYS, it is best to copy the default one from CAR: (TYPE CAR:CONFIG.SYS >>D1:CONFIG.SYS) then edit the latter by adding USE OSRAM line at the beginning (or if there is USE BANKED there, replace BANKED with OSRAM in it). Then save and reboot.

Edited February 24, 2023 by drac030

[reifsnyderb]

11 hours ago, drac030 said:

If SDX did not sense any extension, it would not hang, it would just default to plain 64k configuration. So it seems that it does detect something, but the extension does not work correctly.

 

I of course have no idea why it does not work, but there are two things to mention, perhaps:

 

1) SDX scans the extended RAM not bank by bank, but in portions 64k (= 4 banks) each. The bits 2-3 of PORTB are held %00 during the scan, the remaining 4 bits get flipped. The premise is that if there is a RAM extension at all, it would consist of an integer multiple of 4 banks.

 

2) SDX tries to select the last banks first to load itself, leaving the 130XE-compatible banks free as long as it is possible (e.g. on a 320k RAMBO extension, SPARTA.SYS will be loaded to bank PORTB=$8F). So, if other programs work, but SDX does not, this may mean that out of the entire extension the last 64k is not functional.

 

The mask (PBMASK) you found in the manual is of informational purpose only, its content gets setup automatically during bootup (along with other such parameters, line the number of banks etc.)

 

EDIT: you can of course force the SDX to ignore the extension and use the 64k configuration. To do that, format a diskette (or ATR or whatever medium you use for D1) in SpartaDOS format, save a custom CONFIG.SYS file to its main directory, then bootup from there. Once you get to the DOS prompt, MEM /X will tell you how many banks the system can see. Also you can do PEEK COMTAB+$1C to see what is the extension mask.

 

To make a custom CONFIG.SYS, it is best to copy the default one from CAR: (TYPE CAR:CONFIG.SYS >>D1:CONFIG.SYS) then edit the latter by adding USE OSRAM line at the beginning (or if there is USE BANKED there, replace BANKED with OSRAM in it). Then save and reboot.

Ok.  I used a 320k PBI board and configured the config.sys to use "use osram".  Then, I ran SpartaDOS-X on the 320k 1090 board.  Eventually, and one line at a time, I built up the config.sys to what follows:

 

use osram

device sparta

device env

device sio

device ataridos

device side3

device ramdisk

device quicked

device con64.sys

device doskey.sys

 

There are now only 2 banks left free and it works fine, boots fine, ramdisk works, etc.  The only differences between the PBI board and the 1090 version of the exact same board are that the 1090 version has a little extra logic for the 1090 (i.e.  To enable the data buffer) and it's own voltage regulator.  Without knowing what SpartaDOS-X is doing when the system crashes, I am not sure as to where to go from here.

Edited February 25, 2023 by reifsnyderb

[_The Doctor__]

using stock os, or your wip modified os?

[reifsnyderb]

22 minutes ago, _The Doctor__ said:

using stock os, or your wip modified os?

I was originally testing with my modified OS.  When I encountered problems, I went back to the stock V2 OS to ensure I didn't introduce any problems.  Once I determined the stock V2 OS wasn't the problem, I put my modified OS back in.

[drac030]

9 hours ago, reifsnyderb said:

Without knowing what SpartaDOS-X is doing when the system crashes, I am not sure as to where to go from here.

One thing I can tell you for sure: it certainly does nothing special. It just uses the detected extension banks.

 

To answer your question: ff SDX crashes right after showing the CP prompt, this most probably means that it crashed while attempting to read AUTOEXEC.BAT. This involves a call to the cartridge, and from there, to the kernel. The kernel switches the extension banks, then calls the FMS which is residing there (in USE BANKED mode, that is). The functions called are open file/read data/close file. In meantime much bank switching occurs, as FMS calls are going to and fro.

 

From your config file I can see that you are loading some things to the extended RAM (ENV, CON64, DOSKEY), but succeeding on loading itself does not prove much. Out of all that, ENV and DOSKEY use their banks very little (at least initially), and CON64 must be enabled to take the control, otherwise it just sits there idly. And it is possible that by mere chance you loaded these to the good banks. Or bits occasionally flipping have escaped your notice.

 

Quite contrary, SPARTA.SYS, when it is loaded to the extended bank, uses it very extensively: it is a large portion of actual 6502 *code*, the FMS, which is used virtually all the time. So any, even tiny memory corruption will result in a crash.

 

By the way, how do you know that "ramdisk works"? Maybe please use this CONFIG.SYS:

 

use osram

device sparta osram

device sio

device side3

device ramdisk O,16

 

then fill up the ramdisk with files, then copy them back to another place, then compare with the originals. There are no miracles, if SPARTA.SYS crashes, the RAM must somehow screw the data written to.

 

Edited February 25, 2023 by drac030

[reifsnyderb]

5 hours ago, drac030 said:

One thing I can tell you for sure: it certainly does nothing special. It just uses the detected extension banks.

 

To answer your question: ff SDX crashes right after showing the CP prompt, this most probably means that it crashed while attempting to read AUTOEXEC.BAT. This involves a call to the cartridge, and from there, to the kernel. The kernel switches the extension banks, then calls the FMS which is residing there (in USE BANKED mode, that is). The functions called are open file/read data/close file. In meantime much bank switching occurs, as FMS calls are going to and fro.

 

From your config file I can see that you are loading some things to the extended RAM (ENV, CON64, DOSKEY), but succeeding on loading itself does not prove much. Out of all that, ENV and DOSKEY use their banks very little (at least initially), and CON64 must be enabled to take the control, otherwise it just sits there idly. And it is possible that by mere chance you loaded these to the good banks. Or bits occasionally flipping have escaped your notice.

 

Quite contrary, SPARTA.SYS, when it is loaded to the extended bank, uses it very extensively: it is a large portion of actual 6502 *code*, the FMS, which is used virtually all the time. So any, even tiny memory corruption will result in a crash.

 

By the way, how do you know that "ramdisk works"? Maybe please use this CONFIG.SYS:

 

use osram

device sparta osram

device sio

device side3

device ramdisk O,16

 

then fill up the ramdisk with files, then copy them back to another place, then compare with the originals. There are no miracles, if SPARTA.SYS crashes, the RAM must somehow screw the data written to.

 

Hello,

 

I tried your config.sys, tested the RAM disk, and it works fine.  Anything I loaded into the RAM disk worked fine.  (Even when the RAM disk was full.)  All other memory tests work fine on all banks.  CON64 worked fine.  (ED didn't work while using CON64....but I suspect it won't.)

 

Are there any assumptions the bank switching code makes when determining what sort of banking system is in use?  Is there any documentation, or otherwise, that shows how SpartaDOS-X determines what sort of banking system is on the card?  My suspicion is that I somehow violate those rules with my card.  I also suspect that different software uses different algorithms to determine what sort of banking system is in existence.  But I can't prove or disprove it.

 

My card uses bits 2,3,5,6 for the banks.  Bit 4 enables or disables the banking whereby banking is turned on when bit 4 is zero.

 

Thanks!

 

Brian

[reifsnyderb]

@drac030:  As a test, I neutered my card down to 128k by disconnecting the SRAM pins 1 and 30, from the banking logic, and grounding them.  So there is now 64k of base memory and 64k of extended CPU accessible memory.  There is no change.  SpartaDOS-X does not load and SysInfo 2.24 does not display a complete System Summary.  On the other hand, SimCheck and SimTest, by @Panther, work perfectly.  As another test, I have Prince Of Persia, which requires 128k, running perfectly on this 1090 card even though the test 600XL has only 16k internally.

 

Please make no mistake.  There is an incompatibility with my card and I want to fix it.  I just don't know what the difference is between how the software that works with my card accesses expanded memory and how the software that doesn't work accesses expanded memory.  If there is a way I can compare this I firmly believe I can find a fix for my card.  One, time consuming option, is to manually disassemble the code surrounding all references to PORTB ($D301).  This could take days.  Another option is to see if we can compare the source code for the PORTB subroutines to see what is being called that results in the card failing.  (i.e.  In an early version of my card I discovered that attempting to read PORTB set the bank registers.  I fixed that as soon as I realized that you can read PORTB and it was the problem.)  A comparison of code that works with the card and code that doesn't work with the card should provide for a very quick understanding of and fix for this problem. 

[_The Doctor__]

@ClausB, might there be some light shed on this if the two of you got together.

The upgrade is so very close to fruition, with just this slight stumbling block.

My silly ideas are that banking might be an issue with the OSS banking cartridge present as maybe..

Could it be the series of banks conflicting or exceeding?

Could it be a case of memory being available opposite or during OS enabled / disabled?

Antic following is not the same as separated Antic access. etc.

 

Edited February 26, 2023 by _The Doctor__

[reifsnyderb]

Here's the schematic pictures for the 320k 1090 card.

 

Some notes:

 

The schematic shows 74LS chips.  This is not correct, I just didn't update the schematic.  Where possible, 74F chips are used.  For XL upgrades I always use the 74F04 chip where the inverter chip is called for.  I just checked this board and the only 74LS chips are the 74LS74 and 74LS174.  I do not believe those chips would make any difference.

 

The schematic shows pin 7, on the 50 pin 1090 connector being for refresh, then has /disable next to it.  This is a change I made to the modernized XE compatible 1090 board.  The modernized XE compatible 1090 board is fully compatible with legacy 1090 cards.  Refresh was never used and any legacy 1090 cards.  Because of this, I re-purposed it as a disable pin so that other cards could disable any memory on 1090 cards that support this feature.  The idea being that another card could re-map memory and not only disable the internal computer memory but also disable any memory on the 1090 so as to re-map the memory for it's own use.  (I have parts coming for a 1090 firmware board and I plan to test this feature with in the very near future.  For example, internal BASIC could be upgraded, the floating point package could be upgraded, other drivers could be loaded, etc. with nothing more than a 1090 card.)  This card has a jumper to disable this feature and make it 100% compatible with a standard 1090.

 

I've also realized it should be possible to eliminate the 74x74 chip by using another flip-flop on the 74x174 for bit 4.  A spare inverter, from the 74F04, would be used on the D4 input to the 74x174.

 

Edited February 26, 2023 by reifsnyderb

[ClausB]

4 hours ago, reifsnyderb said:

Here's the schematic pictures for the 320k 1090 card.

Looks like your D301 shadow circuit would mistakenly react to any write access to D303 (PBCTL) as well. Try running A1 into that OR gate instead of A7.

 

I suspect you meant to use A1, and that A7 might have been a misread of your hand-written A1. I always cross my 7s and Zs to prevent confusion with 1s and 2s.

Edited February 26, 2023 by ClausB

[reifsnyderb]

5 hours ago, ClausB said:

Looks like your D301 shadow circuit would mistakenly react to any write access to D303 (PBCTL) as well. Try running A1 into that OR gate instead of A7.

 

I suspect you meant to use A1, and that A7 might have been a misread of your hand-written A1. I always cross my 7s and Zs to prevent confusion with 1s and 2s.

Thank you!  That was it!

 

When I read your post I couldn't believe that I had that screwed up.  I did.  Normally I just copy files from my working schematic, make the changes, then go from there.  So, the 320k 1090 board schematic really started out as a working 320k PBI board schematic and a bunch of changes were made.  So I "should" have never touched the $D301 shadow circuit again.  Since I save all of the revisions, I checked the previous (and working) revision of the 1090 320k board and A1 was correctly used in the shadow circuit.  Somewhere, and for some unknown reason, I changed A1 to A7 then never bothered to look at it again because I "knew" it worked.

 

This same error was on the Compy Shop board but testing shows it still has problems.  I'll have to post that schematic too.

 

Fixing this on the 320k RAMBO board got it working with SpartaDOS-X.

[_The Doctor__]

$d300 and $d301 are general bidirectional multipurpose ports

$d301 is joystick 3&4 on the atari 400/800 line, so has no default value (as it is read only)

$d301 on the 600xl/800xl/65xe etc. line is write only and has value $fd =253

bit 0 on means OS-ROM enabled

bit 1 off means Basic-ROM enabled

bit 7 on means selftest ROM at $5000-$57ff disabled.

 

analmux tried an experiment if the 2kb invisble RAM from $d000-$d7ff would apear on the selftest area ($5000-$57ff) when selftest ROM (part of OS-ROM mapped 32 kb back in memory) enabled but OS-ROM turned off:

 

bit 7=0, bit 0=0: $7e or 126

$fe (254) will turn ALL ROM off. And when you do so, be sure to disable all kinds of interrupts (IRQ/NMI) and then replace the vectors at $fffa,$fffe

 

....and with control registers $d302, $d303 (bit 2 turned off/on?) you can reach the data-direction registers: now $d300 and $d301 are used for setting the R/W direction on the same registers.

 

Incognito gets around the PORT B issue to allow banking, control and joystick use at the same time, some programs might need to read things slightly differently but that covers the gamut from the original line on up with some work. (food for thought since you are doing both hardware and OS work)

[Pfaffa]

3 hours ago, reifsnyderb said:

Thank you!  That was it!

 

When I read your post I couldn't believe that I had that screwed up.  I did.  Normally I just copy files from my working schematic, make the changes, then go from there.  So, the 320k 1090 board schematic really started out as a working 320k PBI board schematic and a bunch of changes were made.  So I "should" have never touched the $D301 shadow circuit again.  Since I save all of the revisions, I checked the previous (and working) revision of the 1090 320k board and A1 was correctly used in the shadow circuit.  Somewhere, and for some unknown reason, I changed A1 to A7 then never bothered to look at it again because I "knew" it worked.

 

This same error was on the Compy Shop board but testing shows it still has problems.  I'll have to post that schematic too.

 

Fixing this on the 320k RAMBO board got it working with SpartaDOS-X.

We have all been there. I remember printing out a 1000+ line Turbo Pascal program in high school because the  compiler was acting like I was missing an End somewhere. Drew lines matching Begins and Ends, and still couldn't find where I messed up. Had someone else look at it and right away spotted that either there was a semicolon was missing or where there wasn't be one. God I felt stupid

[ClausB]

4 hours ago, reifsnyderb said:

When I read your post I couldn't believe that I had that screwed up. 

Nothing we haven't all done before. You did the right thing by showing your work to put more eyes on it.

[reifsnyderb]

Here's the compy shop compatible schematic.  I fixed the problem with the A1 connection to the $D301 decoder and it still doesn't work.  So, it's fixed in the schematic.  As with the previous card, the chips are usually 74F chips and the inverter chip is always a 74F04.  For the most part, it's the same as the 320k RAMBO card but with the banking setup to be compy shop compatible with ANTIC banking.

 

 

 

 

Edited February 26, 2023 by reifsnyderb

[ClausB]

7 hours ago, reifsnyderb said:

it still doesn't work

Symptoms?

[ClausB]

12 hours ago, reifsnyderb said:

Here's the compy shop compatible schematic.

Doesn't CompyShop use PORTB bits 2, 3, 6, and 7 for bank selection? I don't see bit 7 in the schematic.

[reifsnyderb]

5 hours ago, ClausB said:

Symptoms?

Sorry, I've got the symptoms on page 16 of this thread from Tuesday at 10:46PM to Wednesday at 10:56PM.

 

48 minutes ago, ClausB said:

Doesn't CompyShop use PORTB bits 2, 3, 6, and 7 for bank selection? I don't see bit 7 in the schematic.

Yes.  That's my one theory as to why the card doesn't work.  I used bits 2,3, and 6.  I can't use bit 7 because the 1090 card can't do anything to prevent the MMU from enabling the self test bank.

 

[ClausB]

53 minutes ago, reifsnyderb said:

I can't use bit 7 because the 1090 card can't do anything to prevent the MMU from enabling the self test bank.

Maybe @Mathy could chime in on that.

[drac030]

4 hours ago, reifsnyderb said:

Sorry, I've got the symptoms on page 16 of this thread from Tuesday at 10:46PM to Wednesday at 10:56PM.

I looked there again and I am afraid that you are a little bit too concerned with possible assumptions software is making while testing/accessing extended banks. There is no place for particular assumptions, a program has a procedure to count the banks, it then uses (or tries to) the banks it found and it is basically all.

 

The usual procedure consist of a loop which tries out all the possible combinations of the relevant bits of PORTB. SpartaDOS X is no exception. The procedure goes less or more thus:

 

1) bits 2,3,4 in PORTB are set to 0.

2) the remaining 4 bits (7,6,5,1) count from $0 to $F

3) each iteration checks if there is a new bank banked in

4) if so, it marks it as "seen", increases the bank counter and goes back to p. 2.

5) if not, it just goes to p. 2

6) after the 16th iteration the procedure quits.

 

As you can see, there is no special case for 192k, or anything else. It just increases the counter, writes PORTB and looks if anything changed.

 

And it might be worth checking, how many banks this procedure can see in your case. Just use the config above, start SDX in 64k mode, then do MEM /X at the DOS prompt (which will tell you the number of banks the system saw) and PEEK COMTAB+1C (for 192k the mask should be $5C, I think).

Edited February 27, 2023 by drac030

[_The Doctor__]

SpartaDOSX does turn off BASIC however and it handles external and internal cartridge control. Since you've already nailed down one problem maybe a little more exploration can help.

 

Maybe try disk based SpartaDOS, and try original SpartaDOSX before either FTe or DLT versions to see if there is a difference.

Edited February 27, 2023 by _The Doctor__

[+warerat]

Two comments on your design, and this may or may not be the solution but may give you some additional considerations as you expand your use case:

 

- You are gating HALT directly.  The HALT signal is not synchronized to PHI2 and if you're generating addresses with this they will not line up correctly between CPU/ANTIC.  If you want to differentiate with an ANTIC cycle, register HALT on the falling edge of PHI2 and use that as your enable instead of the signal directly from ANTIC.

- All writes to PORTB should not always write to your output register.  Remember the PORTB address is multiplexed to two different internal registers on the PIA, DDRB (direction register) and ORB (output register).  When bit 2 of PBCTL is 1, writes go to the output register otherwise they go to the direction register.

 

[reifsnyderb]

1 hour ago, warerat said:

Two comments on your design, and this may or may not be the solution but may give you some additional considerations as you expand your use case:

 

- You are gating HALT directly.  The HALT signal is not synchronized to PHI2 and if you're generating addresses with this they will not line up correctly between CPU/ANTIC.  If you want to differentiate with an ANTIC cycle, register HALT on the falling edge of PHI2 and use that as your enable instead of the signal directly from ANTIC.

- All writes to PORTB should not always write to your output register.  Remember the PORTB address is multiplexed to two different internal registers on the PIA, DDRB (direction register) and ORB (output register).  When bit 2 of PBCTL is 1, writes go to the output register otherwise they go to the direction register.

 

I didn't consider /HALT synchronization.  I'll take a look at the schematics for other memory expansions with that consideration in mind.

 

On an XL/XE I don't know of any situation whereby PORTB would be not be used for an output register but your thought is an interesting possibility.  That being said, I haven't noticed any problems shadowing PORTB. 

 

The only thing odd, that I've noticed, is that with the 1090 320k board that the reset key may need to be pressed to zero the banks.  Otherwise, the computer may crash on booting and have a light green screen.  Since I have to get a new board made, I'll give that some thought to see if there is a way to eliminate that problem.