Jump to content
Marek Konopka

Project Veronica

Recommended Posts

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

  • Like 8

Share this post


Link to post
Share on other sites

...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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

 

post-26134-0-99996500-1430308638_thumb.jpg

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

 

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

 

post-21021-0-96409800-1430365071_thumb.png

 

And then random characters continue streaming down the page:

 

post-21021-0-72634100-1430365254_thumb.png

Share this post


Link to post
Share on other sites

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.

 

  • Like 2

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by Simius

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

@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

Share this post


Link to post
Share on other sites

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.

  • Like 2

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...