I feel it like the best Oric of all times, but make your mind yourself : if you want to see it in action and are near Toulouse for the upcoming weekend, George has sent me one AtmoStrat so I will be demonstrating it on Saturday afternoon at the Vieumikro annual meeting ( http://silicium.org/site/ ).

Greetings to all !

Fabrice

Side notes:
- the WD65C816S processor is a 8/16-bits cpu, it boots in 6502 emulation mode for a near 100% compatibility with Oric Atmos, and can be switched by software to its native mode in order to benefit from 16-bit registers. On the AtmoStrat, it is clocked at 1 MHz only, in order to keep maximum compatibility with the Orics,
- the 256 KB of DRAM are refreshed by the ULA as usual, and can be accessed both from 6502 emulation mode or native mode. As usual, a fourth of it is only accessible when an external disk controller is attached,
- despite lacking a serial communication chip (ACIA) and the Telestrat specific ULAs, the HyperBasic and TeleAss modes are rendered possible by a software modification of Telemon, and the PB5 bank switching trick. TeleAss might be replaced by TeleForth in the future (and I'm working on a 16-bit OricScheme to provide even more options for native development...)

Last edited by Euphoric on Thu Sep 29, 2016 9:06 am, edited 1 time in total.

I'm sure that George will sell it soon and that amateurs will be able to try it. however, i'd prefer seeing one with an rs-232 and a fdd controller built-in ; it'll be better to link it to a pc for example to transfer files to disk and to use a disk drive or a gotek clone.
Always with a 65C816, the real oric super-vitaminised is the Super-Oric (on SNES)

First congrats to George (jorodr) for the incredible AtmoStrat.
I have this jewel since April (but I had to keep it secret) - it's really cool!
I tested it with Microdisk, Cumana, 8D-FDC and Cumulus and ... it worked fine!

The PCB fits perfect in the standard Oric case - even more, it's designed to be so.
The Video sync is exactly the famous VSync hack. The wiring is made on the PCB and with the jumper
(seen on the picture) you can turn it on/off.

But the most important thing are the two real video pages. They can be switched with one simple POKE .

iss wrote:The Video sync is exactly the famous VSync hack. The wiring is made on the PCB and with the jumper
(seen on the picture) you can turn it on/off.

It's what I thought.
How difficult would it be to make the switch done automatically when not using the TAPE for loading or saving?

When we load or save stuff, we enable the RELAY to start the tape drive, so it should be relatively uncomplicated to automate the VSYNC by having the TAPE-IN to VSYNC connection done only when the relay is not ON.

Okay, let's reveal some AtmoStrat secrets ;
In AtmoStrat the normally unused VIA pin PB5 is used to switch ROM banks.
And the PB6 which drives the tape relay is used to select which video page to be displayed .
Of course all required modifications in all ROMs are done properly by Fabrice (Euphoric).

So, unfortunately the idea to use the PB6 to switch between VSync and Tape-in will not work
with the current version of AtmoStrat.

iss wrote:And the PB6 which drives the tape relay is used to select which video page to be displayed .

Does that switch both the video memory AND the character sets?

That's true...when PB6 is 0 all the ULA's video memory accesses are in $00xxxx (including those character sets memory cycles), and when PB6 is 1 all the ULA's video memory accesses are in $03xxxx.

About PB5, George has cleverly spotted that switching roms with PB5 can be a problem with all those Oric software that assumed that PB5 is a no-connect on the Oric-1/Atmos, so PB5 does not switch roms in Atmos mode : PB5 is only used to switch roms in Telestrat mode, ie. switching between the modified Telemon bank, and the unmodified language rom (currently HyperBasic or TeleAss)...

Dbug wrote:Since 03xxxx is not in the 64k addressing range, what happens if you play with PB6 in 6502 mode?

This is the tricky part - playing with PB6 only affects which memory content will be displayed on the screen i.e.
when PB6=1 it forces the ULA during the DRAM refresh time (when PHI2 is low) to use memory from $3xxxx instead from $0xxxx.
The CPU is unaffected - simply in 6502 you can access only the first 64k and in 65816 mode you have the whole 256k available.
To display video page $3xxxx use: POKE #300,PEEK(#300) OR #40
to display default page $0xxxx use: POKE #300,PEEK(#300) AND #BF

What happens if you change the value while the picture is being drawn, does it immediately change to the other video data?
How does the ULA behave in regard to memory access and CPU accesses: Does it cache anything, can we reach a situation where in TEXT mode the screen value would be read from one location and the character definition from the other location?

I'm trying to see what kind of funny things could be done with that system

Yes, changing PB6 results immediately change of video data - I don't think that ULA caches more data than 1 byte.
Else I can't answer if it's possible to use char definitions and text content from different 64k blocks.
But the fact to have 2 completely independent text/hires pages and 2 full sets char definitions (standard+alt) is good base to start with fun experiments .

Edit: Because ULA access RAM twice in every single PHI2 pulse, it's not possible to have text/char from different 64k blocks, but probably it's possible if we have on text screen ABCDEF, to display A,C,E from one block and B,D,F from the other... or in groups of 2-3 chars, something like that - depending on how fast we can switch PB6.