Project Veronica

[Keatah]

What hardware is this cartridge targeted at? With what memory configurations? What is recommended and what works best?

[Rybags]

In theory no reason it couldn't work on an 8K machine.

 

In practice, no doubt most stuff would assume 40K or better main Ram available. The cart itself has 64K dedicated Ram which the Atari can also see part of.

 

Would be nice to have a decent spec sheet - also what differences exist between the early release ones that went out and the version for sale now.

[Simius]

A couple of questions...

 

1. Can Veronica be used as a slave processor with a system that is already CPU upgraded to a 65816?

2. Would you consider making an Atari 800-specific version of Veronica that could use the Right Cartridge slot? I would think that a 'Right Cart" configuration would sell very well, and become a classic piece of gear.

1. I don't see obstacles.

2. It is possible, but with some limits (lack of S5 and RD5 signal). Besides, it will take some time because although I have a dozen XL / XE machines, but no 400/800.

[phaeron]

Alright, this is a bit raw, but something to play with for those of you with Veronica carts: an early port of Altirra BASIC to Veronica. The main interpreter is running on the 65816 at 14MHz and only calls back to a stub on the 6502 for I/O, so programs will generally run a lot faster, but text and graphics output will run at similar speeds. One big caveat that affects compatibility is that since the strings and program text are on the cart, quite a lot of games that use strings for P/M graphics and USR() programs will not work. POKE/PEEK/USR are reflected, but they fail because ADR(A$) gives an address on Veronica instead of the main CPU. This can be solved by reflecting program code to the Atari side and doing strings on the 6502, but I haven't gotten to that yet.

 

Also, the M/X bits are an evil invention, and I wasted a couple of hours debugging startup hangs caused by #$*% GINTLK.

 

Source is included, for those who might be interested in the communication details. The Veronica side is in comm.s and the Atari side in vhost.s. The way I ended up solving the two-way communication problem was to use the semaphore for Atari -> Veronica signaling and a memory byte for Veronica -> Atari. This way, the 65816 only has to do a BIT/Bcc occasionally. On the Atari side, the 6502 is constantly swapping the windows back and forth to check for a request from Veronica, after which they exchange data via $A000-BFFF (Atari) / $E000-FFFF (Veronica) and signal via the semaphore. Two 16K banks are used for this, with the code duplicated between the two; this allows both the 6502 and the 65816 to execute in the banking window while swapping data and also allows the 65816 to directly insert parameters into the 6502 code. The 6502 normally executes in $BA80-$BFDF with $B800-BA7F used as the communications buffer; for large I/Os both the 6502 and 65816 jump to trampolines and transfer up to 8K via the alternate memory bank pair instead, so that the transfers are big enough for DOS to do burst I/O.

 

There are a few things I found myself wanting during the initial port:

 

• True shared memory between the CPUs. Having to swap memory back and forth and only being able to do so from the Atari side complicates the communication protocol. Also, it precludes the Veronica side from directly writing to a single-buffered display, as the OS normally sets up.
• Flash on the cart. Veronica has no bootstrap capability and occupies the cart port that might be used for a MyIDE/SIDE, so the only choices are disk or PBI device.
• Interrupts or high memory. One of the big problems I ran into with running the 65816 in native mode is that the stack will freely roam over the whole 64K memory space, so if you screw up and the 65816 starts crashing, it'll wrap the stack around the whole address space and obliterate any evidence of what went wrong long before you can catch it.

 

But, this all aside, Veronica works, full programs can be run on it, and the 65816 coprocessor is fast.

 

vbasic-0.1.zip

[flashjazzcat]

...I wasted a couple of hours debugging startup hangs caused by #$*% GINTLK.

GINTLK was clearly conceived primarily as a stress-test for debuggers.

 

Great work, though.

[+Larry]

Since Phaeron released his VBASIC (thanks!!!), this is the first time that I've tried the Veronica cart in several different Atari computers. I discovered that the cartridge shell is too wide to fit in some XL's. In my case, I found that it will not seat in a 600XL. I don't have a lot of 1200XL's, but I tried two of them and the cart won't begin to go into the cartridge "pocket" in the 1200XL. (Maybe this was mentioned earlier, but I don't recall it being discussed.) No problem with an "external" cartridge adapter for an XE or an external adapter such as Metalguy's extender for the 1200XL. Looks close enough for a little filing on the regular XL's, but not on a 1200XL. Also is a really tight fit on my XE's and will not fully seat.

 

A similar type (but slightly different) cartridge shell has the bottom 15 mm. of each side of the cart relieved by about 1 mm (guesstimating), so that may be the fix for the regular XL's and maybe XE's.

 

-Larry

[Simius]

This is true, that the housings used for Veronica are a bit too wide. But rather for the old 65XE (without ECI). With 600XL i haven't any problem. Unfortunately, this is the only decent looking housing, I found. I had only one alternative - some better fitting, but ugly, rough surface, marked traces of the molding machine and no field for label. Look at the enclosed photo.

 

[flashjazzcat]

In other words, a Sic! cart case. Note the Sic! housing won't fit in an unmodified 1200XL either.

[+Larry]

Filing looks like a good fix for my systems, and I have a cartridge extender for the 1200XL's (although I rarely use them.)

 

Simius, when you have a chance, could you try the V1 Veronica with the VBASIC? There could be lots of reasons for it to have issues at this point, but I get "Cannot communicate with Veronica Cartridge" on all the computers I've tried. I'd like to rule out the V1-V2 issue.

 

Thanks,

Larry

[Simius]

Under which DOS you received this message?

[+Larry]

Under which DOS you received this message?

 

MyDos 4.55 booting/loading under SIO.

 

Had an additional question. Is Veronica transparent to the system until called? It seems to be inactive.

 

-Larry

[Simius]

Veronica is invisible while bits 4 and 5 of control register are zero.

Just comming an extended weekend. I'll check what's going on.

[+Larry]

Thanks!

-Larry

[Xuel]

@phaeron Does VBasic work under Altirra or only under real hardware?

 

I get this with Altirra 2.70-test9 right after hitting enter:

 

 

And then random characters continue streaming down the page:

 

[phaeron]

Does the cannot-communicate error happen immediately or after 4-second delay? Veronica BASIC does a simple memory test before attempting to bootstrap, by turning on the $A000-BFFF window and writing a message into the low bank and its inverse into the high bank, then re-checking the low bank message. It'll fail out immediately if the memory check fails and timeout after four seconds if the bootstrap fails. The bootstrap check is not very complex as it basically just requires the 65816 to copy a page to low memory, jump to it, and set the semaphore from there.

 

I did run into some problems with Ultimate1MB. The SIDE option must not be SIDE w/button in the U1MB BIOS, in particular, or else U1MB will block the cartridge port from mapping the $Axxx window. However, I did add code to the loader to force the external cartridge on via $D5E0 if the SDX module is enabled, as the X command will normally shut off the external cart.

 

Veronica BASIC won't work on Altirra 2.70-test9 due to some bugs in the emulation, most critically a broken AND instruction. I need to clean up the fixes to push out a new test release.

 

[+Larry]

On my computers (using a stock 130XE and an almost stock 800XL), a little different this AM. About 2 times out of 3, I get the "Cannot communicate" error, typically within 1 second of finishing the load. But occasionally, there will be a long pause (at least 4 seconds), and the title will be presented "Veronica Basic 0.1..." But it is locked up. Keyboard is frozen, etc.

 

-Larry

[analmux]

A sub-sub-forum focused on this and similar topic subjects would be nice, when it's a bit off-topic with respect to the standard A8 itself.

[dmlloyd]

I'd like to just point out that for less than $20, you could have a much simpler programming model (and simpler logic too): http://www.digikey.com/product-detail/en/CY7C006A-20AXCT/CY7C006A-20AXCT-ND/1205394

 

EDIT: That's high-quantity pricing, but this kind of part is not that much more in single units...

Edited April 30, 2015 by dmlloyd

[Simius]

There is no need to use a biport RAM. RAM in Veronica 2.0 is used by the both processors simultaneously without disturbances. Such memory management (two replaceable banks) is a result of initial assumptions. It could be otherwise, but that would not be Veronica.

Edited April 30, 2015 by Simius

[phaeron]

Okay, Simius managed to get a trace of the problem in a logic analyzer, and we know what's going on now... Veronica BASIC 0.1 is definitely incompatible with Veronica V1. The problem is that the V1 hardware swaps banks asynchronously from the 65816's clock, so if the 65816 is reading or writing to bank memory when the 6502 swaps the banks, the '816's memory access cycle can fail, causing a crash. VBasic swaps the banks back and forth and has both CPUs running code in the bank windows constantly, so the failure happens in seconds instead of perhaps hours to days. The V2 hardware doesn't have this problem because the 65816 runs synchronous with 6502 timing.

 

Neither the base 64K memory on the '816 side nor the semaphore bit have this issue, so those are safe and it's only the swappable memory that's vulnerable. Problem is, VBasic relies on fast swapping of the memory bank for one of the communication channels in its fast two-way protocol. I'd have to sit down and think about how the protocol could be reimplemented in a way that would work with the V1 hardware.

[+Larry]

@Phaeron-

 

Glad you guys found the problem, but neither you nor any other developer should have to "work around" V1-V2 difference(s). They were supposed to be completely compatible.

 

-Larry

[phaeron]

Well, technically, it is true that V2 is compatible with V1 -- any software that works reliably on V1 will work reliably on V2.

 

Regardless, that's where we're at. There's a chicken and egg problem between hardware and software development, and low-volume work like this magnifies that. Veronica BASIC is probably the most complex program that's been attempted on the hardware so far, so it was apt to find problems like this. Working around the problem in software isn't ideal from my standpoint, of course, but part of the challenge for working on a limited platform like this is working with what you have. Otherwise, it'd be much easier to work in C++ on my cushy Core i7....

 

At least now that the problem is known, I can attempt to emulate it, which would make it easier to verify V1 compatibility.

[jvas]

Okay, Simius managed to get a trace of the problem in a logic analyzer, and we know what's going on now... Veronica BASIC 0.1 is definitely incompatible with Veronica V1. The problem is that the V1 hardware swaps banks asynchronously from the 65816's clock, so if the 65816 is reading or writing to bank memory when the 6502 swaps the banks, the '816's memory access cycle can fail, causing a crash. VBasic swaps the banks back and forth and has both CPUs running code in the bank windows constantly, so the failure happens in seconds instead of perhaps hours to days. The V2 hardware doesn't have this problem because the 65816 runs synchronous with 6502 timing.

 

Neither the base 64K memory on the '816 side nor the semaphore bit have this issue, so those are safe and it's only the swappable memory that's vulnerable. Problem is, VBasic relies on fast swapping of the memory bank for one of the communication channels in its fast two-way protocol. I'd have to sit down and think about how the protocol could be reimplemented in a way that would work with the V1 hardware.

Thanks for the update. And more thanks for your efforts. I have V1 Veronica, so if you need testing, please let me know.

[+Larry]

Just a thought about a possible use for Veronica. Could Veronica be used to improve the SID emulators using Pokey? Maybe a dumb question, but seems like a large increase in available cycles might be useful to improve the emulated sound?

 

-Larry

[vazquezrick]

Hello all,

 

I seem to having an issue with the skull demo. I run the biosload file, it loads fine. I r.bat @r hit the space button and I get nothing but a blue screen. What I'm I doing wrong?

 

Thanks