Incognito JED experimental upgrade

[flashjazzcat]

Mosaic is selectable now (the non-trivial matters of finding space for menu revisions and some means of packaging the new selection bit in the config having been dealt with), but I cannot get the machine to boot with Mosaic RAM enabled. I guess it's over to Candle now, unless I am missing something (and no, it's not that system RAM needs to be 48K: tried that too).

 

Edited October 2, 2021 by flashjazzcat

[candle]

when mosaic was on, system got unmaped

 

main.jed

[Faicuai]

This is F-AMAZING guys!

 

For historical or productive purposes, you guys managed  to support pretty much ALL RAM memory models pre-dating the XL-era (16K-48K, RAMROD +4KB, AXLON 1MB and Mosaic +144K) plus the most valuable ones from XL/XE era (RAMBO 320K, 1088K) and CompyShop 576K (with separate ANTIC access) !!

 

In other words, an ALL-in-ONE memory upgrade package, which hopefully maybe part of upcoming Incognito/400, so that entire user base can also enjoy the this wholesome, feature-packed bundle!

 

@flashjazzcat: Jon, please, consider running the little Mosaic bank-test I posted on the prior page, as it will attempt to scan all possible banks, identify them from an actual bank, a repeated one, or floating-bus, and ultimately test them for integrity. On the other hand, I could do all of this for you guys, If I have access to the beta Bios for setting it properly, and perform a full "regression" test just to make sure everything else works fine. Your call.

 

@candle: just a couple of Qs: (yes or no is fine, no need to expand answer, if you can't)

 

a) Considering that everything seems in place now, is there any (remote) chance that once Mosaic 144KB is selected as it shows on Jon's BIOS (no further changes), the remainder (1024-144 = 880KB) would be still made available as AXLON by just having the CPLD ignore the last 9 AXLON banks when sensing writes on $CFFF if-and-only-if bit#3 of $D380 is set? This would enable simultaneous support of both RAM models, which means we could run SDX in Colleen mode while, at the same time, have full access to Mosaic banks on $C000-$CFFF.  That would be sick!!

 

b) Is there any possible way to write-lock the 52KB default $C000-$CFFF bank (make it read-ONLY at will), by using exact same Mosaic latch-address model, just one byte below or above its current range or any other simple way? By doing so, you will close-the-loop with RAMROD emulation (virtual "EPROM" on $C000-$CFFF, also with NO further changes on Jon's BIOS !

 

In any case, just food-for-thought, as it is already WONDERFUL to have support of Mosaic. as is, and I am ready to re-test here, when you guys are.

 

 

[candle]

for every 4k of mosaic bank another 12k gets wasted

this uses the same banking register as axlon (or standard portb memory expansion for xl/xe mode) uses, plus, i have only control over address lines A14 and above up to A18

for ROM it is A12 up to A18 so I can have 4k banks for ROM, but not for RAM

 

with some work it might be possible to have 128k mosaic + 512k axlon but it might just not fit into cpld

 

as for making c000-cfff read only it is possible, but sinice no previous standards were set for this, this needs some thinking over on how to approach it, and what would use it

first thing that comes to my mind is to loader to handle loading any kind of ROM image into this area, and setting write-lock-till-reset bit then, so you could preload any piece of software you would like to use for that session, and you're done

 

as for your test-suite - it crashed, so we need some atomic, simple tests instead

 

[Faicuai]

15 hours ago, candle said:

for every 4k of mosaic bank another 12k gets wasted

THANKS, this explains everything.

 

15 hours ago, candle said:

as for making c000-cfff read only it is possible, but sinice no previous standards were set for this, this needs some thinking over on how to approach it, and what would use it

This will enable Newell's OS/N to run as originally (and fully) intended: OS/N on $E000-$EFFFF and $F000-$FFFF ROM blocks (total of 8KB) for core OS/b-compatible code, and then choice of OMNIMON or OMNIVIEW residing on $C000-$CFFF, which work hand-on-hand with OS/N load.

 

This is how RAMROD board actually works:

 

1. ROM Math-pack on $D800-DFFF (==> already supported on Incognito)
2. ROM or EPROM on $E000-$EFFF (==> already supported on Incognito) 
3. ROM or EPROM on $F000-$FFFF (==> already supported on Incognito)
4. EPROM or RAM on $C000-$CFFF (==> You already got the RAM part done, here. Only "EPROM" mode is missing)

 

15 hours ago, candle said:

as for your test-suite - it crashed, so we need some atomic, simple tests instead

 

Please, make sure OS HW/Initialization DOES NOT size RAM up to $D000, because it will open DL and E: session buffer on $CC20-$CFFF and it will be brutally overwritten by Mosaic bank-test utility.

 

To avoid it, please, configure Colleen's Basic ROM as ACTIVE (it will lock $A000-$BFFF, thus restraining the OS from scanning RAM higher than $A000), or simply go to SDX, and launch from SDX *WITHOUT* X command (just typing TSTMOS64 at prompt).

 

That should work (just tested it here).

[flashjazzcat]

45 minutes ago, Faicuai said:

Jon, please, consider running the little Mosaic bank-test I posted on the prior page, as it will attempt to scan all possible banks, identify them from an actual bank, a repeated one, or floating-bus, and ultimately test them for integrity.

This would be very nice, and it's the first thing I tried. However, it currently crashes spectacularly, so I am resorting to EYE2 and some other other pragmatic tests, to be continued tomorrow.

 

Edit: I see that Sebastian already explained this. Caveat regarding BASIC noted.

Edited October 2, 2021 by flashjazzcat

[Faicuai]

2 minutes ago, flashjazzcat said:

Edit: I see that Sebastian already explained this.

Reason of "crash" just explained above, and how to run it.

 

Hope it works now (just tested it here).

[Faicuai]

4 hours ago, flashjazzcat said:

Edit: I see that Sebastian already explained this. Caveat regarding BASIC noted.

FYI my apologies for the last-minute update, but there is a very small (but significant) error on the Mosaic test-utility code.

 

Please, use this version, which correctly "indexes" Mosaic banking registers:

 

tstmos64.act (source)

tstmos64.com (executable)

 

The reason for the error is the result of a prior optimization aimed at creating a common body of code for another test-utility capable of testing AXLON, too. As a result, both "static" or "variable" banking-registers are supported, but the math needs to be updated in the code... which I accidentally ignored, thus never really testing Mosaic past Bank #00 ... 8-(

 

The above works on ACTUAL A800 + Moisac-64 HW, and uses original Mosaic registers. If Candle's Mosaic emulation is using OTHER registers, these could be very easily updated by adjusting only two lines / parameters on source code.

 

As before, please execute with Basic or SDX carts active.

 

Cheers!

 

[candle]

8 hours ago, Faicuai said:

EPROM or RAM on $C000-$CFFF (==> You already got the RAM part done, here. Only "EPROM" mode is missing)

and how this EPROM mode is invoked?

[flashjazzcat]

7 hours ago, Faicuai said:

Please, use this version, which correctly "indexes" Mosaic banking registers

This tool won't run under SDX in Colleen mode; MEMLO is > $4000 since no extended RAM or Shadow RAM is available. Perhaps you could compile it to run at $5000/$6000.

 

I spent twenty minutes writing something which loads at $6000, anyway, and I suspect there is a problem with banks $20-$23, since if I limit the test to $00-$1F, all is well:

 

 

When the test includes banks $20-$23, the test pattern appears to overwrite banks $00-$03.

[Faicuai]

4 hours ago, candle said:

and how this EPROM mode is invoked?

DIP Switch #2 (blue), on the right of the picture:

 

 

It's physical. Once the switch is set, you populate the top-right two sockets (which comprise $C000-$CFFF) with either RAM, or EPROM. In the picture, my board is configured with RAM, so read+write in $C000-$CFFF. However, if you chose EPROM, you can install a 4K EPROM extension for OS/N in there (OMNIMON, OMNIVIEW).

 

So being able to write-lock existing $C000-$CFFF (somehow, at will) will close the loop there with RAMROD EPROM facilities.

 

[Faicuai]

58 minutes ago, flashjazzcat said:

This tool won't run under SDX in Colleen mode; MEMLO is > $4000 since no extended RAM or Shadow RAM is available

Currently, it loads around ~$2D00.

 

The tool is designed to also run on original 800 config., with both AXLON and 52KB ram (so the $C000-$CFFF single-bank region enabled by RAMROD can also be tested with the same utility from SDX or DOS, on legacy HW). This means keeping the code out of the $4000-$7FFFF window to avoid accidental self-banking-out during execution.

 

In your case.just boot from SIDE loader (with basic enabled) or simply from SIO (with Basic enabled in Colleen mode).

 

That should work, and will build and report complete map of Mosaic banks (including RAMROD single-bank). Please, power-cycle to clear all ram between tests, as memory retention is also tested (for RAMDISK use, etc.)

[flashjazzcat]

I booted it over SIO, and results helpfully confirm what I already encountered:

 

 

So bit 5 of the bank selection isn't working. Candle says he will have a look this evening. I added a disable test as well, and that looks a bit squiffy.

Edited October 3, 2021 by flashjazzcat

[Faicuai]

2 hours ago, flashjazzcat said:

So bit 5 of the bank selection isn't working.

Correct, attempts to switch the last four banks yield in no bank-change.

No doubt.

[candle]

36 banks is more then single 512k chip can handle..

 

updated jed...

 

main.jed

[flashjazzcat]

Passes test, all 36 banks.

[candle]

one last change for a good night (disable part)

main.jed

[candle]

and this is finall one for mosaic adventures...

 

main.jed

[flashjazzcat]

...and supporting firmware:

 

Incognito Firmware 041021.zip

 

Loader didn't change, but main BIOS and PBI BIOS did. Owing to aggressive optimisations needed for Mosaic settings, some configuration bits moved around, so check your profiles after the update (the Colleen mode select bit moved, so you might get a surprise the first time you jump into the setup menu).

 

Also included is the no-frills MOSTEST.XEX tool, for testing Mosaic banks. You should get a base RAM error in 48K mode, and base RAM good in 52K mode.

 

Oh... and some breakage is wholly possible, so please report anything bad. Once I know everything works, I'll bump the version number (only revision date changed so far).

Edited October 4, 2021 by flashjazzcat

[_The Doctor__]

Now I need two more of these!

Thanks guys...

just one or two more 'magic' requests though...

how to explain it to the wife! ... as well as an in budget source to make it all happen

Edited October 4, 2021 by _The Doctor__

[candle]

57 minutes ago, _The Doctor__ said:

how to explain it to the wife!

 

just don't - all you can hope for is a polite smile at best...

 

[Faicuai]

On 10/4/2021 at 8:22 AM, flashjazzcat said:

Oh... and some breakage is wholly possible, so please report anything bad.

Alright!

 

So been testing for quite a while, here's the bottom-line:

 

1. Since Mosaic and AXLON shared common facilities, I updated my test suite to v.03, supporting both MOSAIC and AXLON with essentially same code-base.
2. A host of improvements have been added:
   • MOSAIC-deselect test, on either 48KB or 52KB base-ram configs.
   • Detection of accidental bank-switch-out while being tested.
   • Ramtop/himem auto-range & auto-trim, so tests can now be launched reliably from SIDE Loder & SIO, with NO carts needed.
   • Improved granularity / precision during RAM and bank-switch registers read/writes.
   • Test suites require $2300 to $3800 to run, good for Atari DOS, DOS XL, MY DOS, & SDX *with* extended RAM.
3. Ran some cross-tests (e.g. ran MOSAIC test on AXLON config, and AXLON tests on MOSAIC config.)
4. The following configs where tested:
   • [48K +  0K] + [36*4K=144K Mosaic]:
   • 
   • [48K + 4K ] + [36*4K=144K Mosaic]:
   • 

• [48K + 4K ] + [64*16K=1024K Axlon] (here "bootstrapped" into a XEP80 session directly from SIDE loader, for max. long-test speed, since it is capable of testing up to 4 MB of AXLON ram!):
• 

 

At this point, everything seems working really well, and I like how Colleen's 52KB base-memory mode preserves a SEPARATE 4KB bank from Mosaic's own 36, yielding a total of 37 under-test banks on that config. Well done!

 

Here are the source and executables files comprising v.03 test-suite:

tstaxlon.xex tstmos64.xex

tstaxlon.act tstmos64.act

 

IMPORTANT during-test OBSERVATIONS & ANOMALIES:

 

1. Systematically experienced RANDOM profile-resets when powering-up system with Ultimate/SD cart plugged in, XEP/80 plugged to Joystick Port#2, and AXLON/MOSAIC modes selected. These disappeared when removing Ultimate/SD cart and disconnecting XEP before powering up (connecting later, NO problem). Since I do have a Motorola high-performance PIA (in place of stock unit), I will be tracking this closely, and if I come with the exact sequence that triggers this, I will report it here. For now, stays on my side.
2. Still UNRESOLVED / PENDING prior BUG: Ultimate/SD's .XEX Loader DOES NOT work with this latest .JED, but I can't pinpoint if the problem is on Ultimate cart or the .JED update. This is REPEATABLE, and all it takes is attempting to load an .XEX with latest .JED in place.

 

That's all for now!

 

 

[flashjazzcat]

1 hour ago, Faicuai said:

Systematically experienced RANDOM profile-resets

I still get these on my machine (I removed the 16 frame power-on delay kludge from this BIOS, and had to put it back to make my 800 usable). I wondered if you would still experience them too.

 

This seems to be the main stumbling block with the updated JED. Not sure how we should proceed here.

[Faicuai]

51 minutes ago, flashjazzcat said:

I still get these on my machine (I removed the 16 frame power-on delay kludge from this BIOS, and had to put it back to make my 800 usable).

You may notice my recent narrative regarding latest tests...

 

I DO NOT see them ever if clean-cut booting the system (no cart, no XEP on J-port #2, etc.), with your BIOS-delay present.

 

HOWEVER, if I connect XEP on J-port#2, leave it on, and then Power-up the 800 (with our without a cart on it), I may get random Profile #2 or Profile #3 reset... which can be mitigated by pressing BIOS hot-key, once more. 

 

The interesting thing with the above finding is that it seems PIA-related, by most counts (!)

 

Q: is it normal NOT to land on last-used profile (before power-cycle) when powering-up hands-free (just the power-switch)? Even with no profiles-reset of any kind, I am landing on Profile #1, no matter which one I visited on prior session.

[flashjazzcat]

14 minutes ago, Faicuai said:

Q: is it normal NOT to land on last-used profile (before power-cycle) when powering-up hands-free (just the power-switch)? Even with no profiles-reset of any kind, I am landing on Profile #1, no matter which one I visited on prior session.

No that's abnormal. Once you select a profile, you should stay in it until a) you select a different profile, or b) remove the battery.

 

To be absolutely clear: there is no extra power-on delay in the most recently uploaded BIOS. I had to reinstate it in my local copy here, however, since my machine is completely unusable without it (chronic, constant profile resets).

 

Investigations with the scope and debugging BIOS builts showed that chip select is not properly asserted on the DS1305 when the profile reset occurs. This results in the 6502 getting nothing but $ff from the SPI register, instead of the proper contents of NVRAM. Injecting a few extra frames of time between power-on and first access to NVRAM fixes the issue for reasons apparently beyond anyone's comprehension.

 

We observed exacerbated 'profile reset' behaviour with NTSC ANTIC, which I expected, since I hypothesised that since the NTSC frame duration is shorter, the power-on delay is also shorter; hence the problem got worse until the 16 frame delay BIOS was flashed.

 

If this doesn't point to a determinate relationship between the issue and the elapsed time since power-on, I don't know what it suggests, but what would I know about it.

Edited October 6, 2021 by flashjazzcat