Incognito JED experimental upgrade

[candle]

ok... 

try this one

 

 

main.jed

[HiassofT]

12 hours ago, candle said:

800 needs to be on, but i can't program itself, so you would need another one to get the job done

 

this concept of using joystick port for programming these old cpld chips has been in my mind for quite some time, there is serial vector format (SVF) https://www.xilinx.com/support/documentation/application_notes/xapp503.pdf that would be convinient to do just this, but software on atari side is missing

if anyone is willing to develop it - let me know

 

Some 15 years ago I did something similar for Lattice iM4A5 CPLDs (which I used in the 2005 Turbo Freezer).

 

That wasn't too hard, Lattice provided sample C code to perform the JTAG programming, that only needed a few changes to access PIA pins (and probably some adaption for cc65) and the Lattice toolchain also was able to generate a more compact, binary vector format for that purpose (a lot smaller than SVF).

 

Major showstopper though was that the caps and inductors at the joystick port killed the edges and even with schmitt-triggers added I couldn't get it to reliably program the CPLD (with direct connection to PIA it worked, albeit quite slow compared to PC programming). I hadn't pursued that further, so not 100% sure if it was a minor issue to solve or a major one.

 

I don't recall Xilinx provided something similar to the Lattice ispvm-system (IIRC that's what it was called) programming and IIRC Xilinx also recommends against using SVF for their CPLD programming (though it worked quite well here on a PC with a parallel port bit-banged JTAG adapter - several years ago).

 

so long,

 

Has

[_The Doctor__]

the X-COM Wedge by Bachman uses the compy/antic/XE memory access as well especially when using the formatter under spartados disk based versions

[Faicuai]

4 hours ago, candle said:

ok... 

try this one

 

 

main.jed 122.64 kB · 5 downloads

 

Bravo!

 

Looks like we are going places! 8-)

 

Here's a summary of re-test of issues reported on this thread:

1. Post #40 & #42, Item 2.a (no access to 130XE extended banks, and main-memory corruption, CompyShop? SOLVED.
2. Post #40, Item 2.b (Prince-of-Persia, Pang, etc. crashing on black-screen before reaching Palace-scene, CompyShop):  SOLVED.
3. Post #37, Item 3 (.XEX loader failing on Ultimate/SD cart): PENDING.

Items #1 and #2 above (now resolved) are huge. THANKS! 

 

Now, it seems we still have #3 pending from above summary, which is bizarre, because (according to my theory), it should have been already fixed! I am not really sure if it is a .JED or Ultimate/SD-loader issue (and the problem also disappears when rolling back to production .JED) .. but both are involved, for sure. Any of the attached .XEX on this thread (or .REX renamed to .XEX) can be used as samples for loading on Ultimate/SD and verify load-corruption problem there.

 

In the mean time, tomorrow I will run a full-regression test (including PBI, and a myriad of other things) just to make sure everything that was working is still fine-and-dandy.  8-)

 

Cheers!

 

 

 

[candle]

trouble is, i don't have ultimate cart - i'll ask around though...

 

[flashjazzcat]

My Incognito 800 is dead here; the machine lay in bits for weeks after the last round of oscilloscope tests, and now it's reassembled it boots to a red screen. Will test when I overcome that obstacle.

 

[flashjazzcat]

CPU was dead. Nice. With latest JED, UFLASH had problems ID'ing the hardware at first, but once I got the BIOS flashed (without the extra startup delay), config reset problem is worse than ever.

 

[HiassofT]

12 hours ago, HiassofT said:

I don't recall Xilinx provided something similar

In fact, they do. Quick search turned up xapp058:

https://www.xilinx.com/support/documentation/application_notes/xapp058.pdf

https://www.xilinx.com/support/documentation/application_notes/xapp058.zip

 

The zip contains the C source code for embedded XSVF programming, might be a bit of work to get that running on the Atari though. It looks like it wants to have the whole XSVF in RAM, which is about 80k for the XC95144XL (erase+program+verify). Adapting the code to stream the data from the XSVF file might be feasible, this is left as an exercise for the reader though ?

 

so long,

 

Hias

[HiassofT]

Seems I had a too quick glance at the xapp058 code, the readByte function in ports.c already seems to stream from the input file (using fgetc).

 

So probably only the usual cc65 porting will be needed, i.e. making sure temporary data structures fit into memory and data types are correct.

 

so long,

 

Hias

[Faicuai]

25 minutes ago, HiassofT said:

making sure temporary data structures fit into memory and data types are correct

There's just one "little" issue here:

 

It appears that the target CPLD remains in charge of bus logic/control functions even when being flashed... and that means the integrity of 0KB-64KB map (plus some extended banks) MUST be secured during such process, because the flash code itself would run in that footprint.

 

I mention this because when flashing Incognito from Impact (in-situ, powered-up on bus, and showing Bios screen), the whole screen will go crazy and corrupted, shortly after the flash starts, and it will end-up like that once it completes. That means one thing: that something happened to content of $0000-$FFFF, somewhere, somehow.

 

Sounds to me (in my very limited and intuitive knowledge) like the CPLD will need to be "restrained" if being flashed from the same system that it is actively providing bus-logic/control functions to.

[candle]

you just can't do in situ programming of cpld - 6502 is likely to crash no matter what you do

cpld acts here as MMU, and all of the sudden, all pheripherals, ram and rom is off the bus - cpu will continue executing instructions from thin air...

 

[HiassofT]

Of course it will never work to do the programming from the same machine. During programming all I/Os are tri-stated so you'll have no MMU in your system.

 

Using another Atari to program the CPLD (instead of using a PC, impact and xilinx cable) should be doable though.

 

My motivation for looking into that back then when I created the 2005 Turbo Freezer was that it would allow us to supply a very cheap, passive, joystick cable together with the Freezer and people would have an easy possibility to update the logic (and as the Freezer is an external device it would even have been possible from the same machine).

 

Signal edges ruined that (rise/fall times were way above the maximum specced values), other than that it worked fine. I still think it could be doable with some active adapter, maybe similar to the PIC programmer.

 

The XC95144XL is used on quite a bunch of Atari upgrades so having a possibility to update that from an/another Atari with a cheap joystick port solution could be interesting for lots of users so this isn't a too stupid idea at all.

 

so long,

 

Hias

[Faicuai]

12 minutes ago, HiassofT said:

Using another Atari to program the CPLD (instead of using a PC, impact and xilinx cable) should be doable though.

Ok, so I see the main value proposition: a spare Atari to program another CPLD-based host... or we could (in theory) send +5V directly from Joystick port as well, to light-up and program just an external board (useful for developers, too...)

 

In any case, it does sound worthwhile. Getting rid of Impact is already a blessing, on its own. :-))

 

 

[Faicuai]

On 8/27/2021 at 3:01 AM, candle said:

double buffered bus has now write through capability

Very imteresting (there seems to be plenty of effort behind this latest .JEDs)

 

Please, forgive my ignorance, but ... what bus-lines are being double-buffered? 

 

Thx!! 

[candle]

data bus lines, as in original 800 design

this is to enable 800 to use vbxe slot 3 adapter board

 

[Faicuai]

52 minutes ago, candle said:

data bus lines, as in original 800 design

Thanks! (and I can see the importance for VBXE, for sure)

 

Also, quick question on possible memory-management features for Incognito (in COLLEEN-mode):

 

1. How difficult do you think would be to implement Mosaic-64 compatibility on Incognito (e.g. 4KB banks through ($FFC0-$FFE3) write-address, up to total of 144 KB or even more, equivalent to >= 36 Banks of 4KB each)?
2. How difficult would be to implement the ability to designate or lock $C000-$CFFF region as [read/write] or [read-only] (on the fly), so we could also load it with Omnimon, Omniview, etc. to ensure full compatibility with RAMROD and OS/N? 

 

With those two features up there, you would have closed the loop with Incognito and brought in pretty much all of the 800's pre-XL memory expansions models, for historical preservation and posterity. Can't think of any better or more robust RAM-upgrade for the A8, anywhere.

 

My 0.02c

[candle]

chances are slim, since we're at 91% of resources and changing a single line leads to "can't find the fit" messages sometimes

i would need some technical details before i could try to implement this

 

[Faicuai]

8 minutes ago, candle said:

chances are slim, since we're at 91% of resources and changing a single line leads to "can't find the fit" messages sometimes

i would need some technical details before i could try to implement this

 

 

Wow, that's pretty tight already (definitely make sure VBXE support gets completed first).

 

However, it does seem a rather simple-minded banking model. Check this out (I actually tested this on real HW and wrote a RAM-test utility for RAMROD+MOSAIC, and the memory on that window actually works really nice):

 

 

The good thing is that $C000-$CFFF ram-window is already there, already implemented in Colleen mode. All needed is the write-latch address support, and bank a portion of 1024KB into that window, if that option is enabled or configured. Sort of splitting a fixed portion for AXLON and the remainder for Mosaic-64, only if the latter option is selected on BIOS or even through latch-address.

[flashjazzcat]

Getting things to the point where the machine will boot reliably (remember the NVRAM bug?) with the handful of existing improvements would be a good idea before attempts are made to add anything else.

[Faicuai]

59 minutes ago, flashjazzcat said:

Getting things to the point where the machine will boot reliably (remember the NVRAM bug?)

Fully agree, and have two uniquely configured 800s here, and can help you guys anytime with whatever resources I have, unconditionally.

 

On 9/27/2021 at 10:07 PM, Faicuai said:

Post #37, Item 3 (.XEX loader failing on Ultimate/SD cart): PENDING.

 

Any hopes with this strange issue, that is only happening with Ultimate/SD loader? Have been trying to get around it, and no chance, so far....

[candle]

to enable mosaic - set bit 4 of d382 while in bios (that is Jon has to support it)

select memory configuration to 48k, and hw type to coleen

do not enable mosaic and axon in the same time, as they share some resources

 

main.jed

Edited September 30, 2021 by candle

[_The Doctor__]

@candle is on fire... I love your work!

[Faicuai]

33 minutes ago, candle said:

to enable mosaic

Whoaaa!!

 

That was F-fast!!

 

Will be fully testing here, today, and also post mem-test utility I wrote exclusively for RAMROD / Mosaic purposes!

BRAVO !!!  ??

[candle]

mind that it is fully untested as i'm in the office

 

[Faicuai]

4 hours ago, candle said:

to enable mosaic - set bit 4 of d382 

 

Ok, have not got yet to the part of directly writing @ $D382 while in unlocked in BIOS, but here's the Mosaic memory-test, which will attempt to scan, identify and ultimately test each available bank on the $C000-$CFFF (developed and tested on real Mosai HW):

 

tstmos64.act

tstmos64.com

 

Source in Action (.ACT), and compiled version which runes pretty fast (in .COM file), which will load around ~ $2E00, high-enough for SDX, older-DOS versions, etc.