Denial

I remember VIC 20 as the friendly computer; but sometimes I forget how unfriendly it can be, real hardware and emulator alike, for anyone else that wants to trial it. Different memory configurations, resetting the VIC (and IEC drive), the LOAD/RUN sequence, stuff like that can get clumsy to operate even to a veteran.

PRG Starter is cool and helps a lot in the emulator "quick launch" scene. And there are more than a few disk menu utilities to run a program, sometimes with fast loaders, etc.

But sometimes I just want to take out my real VIC or emulator and have it run like a kiosk for my non-VIC peeps -- the kind that have a short attention span for some of these little games, but want to see it boot up and maybe try it for a while. Any of this sound familiar?

This got me thinking about exploring the game cartridge space some more. At first, I was thinking of making just a dedicated autoboot cart for a single game that could use an expansive VIC graphic API in the ROM... but more to follow up on that later. First, I needed a working autoboot cartridge.

I am labeling it "ABC". It's an ALPHA release, so it is primitive. It does work its way quickly down the IEC drive chain from #11 - #8, because I want it to use my uIEC drive (defaults as #10) first when possible. I expect to be improving it over time, but I want to move on next to adding "modules" to it, such as that expansive VIC graphic API that alleviates a standalone PRG from having to embed it as part of its binary. I want to think of that as the Super Expander for VIC arcade games.

FWIIW, I took the liberty of gathering the standalone PRG files from each release year since 2011 through today, plus I made a separate one for the Denial Archive (although its Zombie Yard looks to me as corrupted?). There are more than a few broken links, complex utilities, and D64 images that would not fit the bill, so my apologies upfront if something is missing. This is my early attempt to test ABC, while perhaps making a convenient disk image for peeps to use.

You can download the vic20-denial-* disk images from here. Note that the archive disk is in d71 format. The same download directory has a copy of abc in both prg and a0 format.

I launch it thus:
$ xvic -memory all -8 vic20-denial-2014.d64 -cartA abc.a0

The RESTORE key (PgUp key on VICE) will mostly work if the PRG did not remap it for its own needs. The emulator's Alt-F9 or real hardware RESET switch will warm boot and go back to the ABC cart program.

Interesting. I don't get it to work in VICE. It says some disk error and then insert an ABC floppy.

Yes, it seems enabling True Drive Emulation is a requirement for this to function under VICE. Not a bad thing, mind you, but unless an expert can explain why that is for me? Is it related to sending the "UI-" command string to an un-emulated drive?

True drive emulation doesn't help here. It says "8:74, Drive not ready".

It works for me.

The UI had some strange aspects for me: when there's a "ABC" disk inserted in the drive, I'd expect ABC to show the list of programs directly, the current screen setup looks as if a "non-ABC" disk has been found, prompting the user to tap RESTORE again and again. That STOP actually leads to that list is slightly counter-intuitive.

I then tried the 2013 collection. fcbpaint bombs out with a ROM cartridge in $A000, it needs a full +32K RAM expansion. When I soft-loaded the ABC file from disk (and made an Alt+R soft-reset), it worked. Spiderman also started.

OTOH, when trying out a "non-ABC" disk image, I got mixed results: MINIPAINT stops with a "SEARCHING FOR T" (???), the recently revised boot loader of my games collection just would return to the ABC menu - the second file, SPLASH, though works and carries one through to the menu. And you can expect people to use ABC as generic loader for all disks.

At first I thought, that the "ABC"-disks would contain the necessary information about all the RAM configurations in the first file of each disk, but now it looks as if the ABC boot-ROM just "guesses" the necessary RAM configuration from the start address of each file. That's already done in a similar way by nbla000's cbm-fb - so there's no advantage here.

Sorry if this looks like a random collection of thoughts. The idea has some potential, and I think a simple boot ROM could have its advantages. But simple may be better, maybe just load the first file from disk, or?

Thanks for the feedback guys. I get that this is not addressing anything new, especially for an emulator which has its own challenges. And ABC will make its requirement 'real' when it has an API embedded for programs(s) to use. I am warming up to that concept, but I did want to see if existing standalone PRGs could at least be launched in this manner.
I will be playing with this more exclusively on real hardware, but only after I got a working prototype and demo to show what it can do.
I don't loke reinventing the wheel, so maybe after that, I can get someone's more useful loader to integrate.

I am using latest vice 2.4.10 and vdrive does absorb UI-. I nuked it's vicerc and run it using defaults (true drive emulation is on) and it works fine. If I toggle it off and re-run, it fails to recognize the c15 41 created disk image attached, even though manually attaching it shows the disk contents.

Even without the ABC cart, the BASIC LOAD "$",8 claims device not present.

Now if I add -virtualdev (with true drive emulation off in its saved config) it works, except the "$ABC=P" appears to fail to retrieve only that directory entry, like a real drive.

Unless I am mistaken with the directory pattern command, I may need to submit a feature report to the project.

I tested from BASIC and vdrive does not return the dir entry.

Yep. I checked against my 1.16 and 2.4.2 installations of VICE, and VDrive with a mounted *.d64 does not work with "$ABC=P", neither "$:ABC=P" nor "$0:ABC=P". That should be put in the bug tracker.

In the meantime, doing an OPEN instead with "ABC,P,R" or "0:ABC,P,R", reading two bytes and checking ST (and closing the file again) is a possible workaround.

VDrive on a mounted PC directory has no way to check for a certain CBM DOS file type, and matches on the file name only.

Ah, I forgot about that ", P" in a regular open command, thanks.

FYI, I did post that VDrive "feature" for the VICE project to consider, and I refreshed the floppy images (listed above) with my consideration of its non-intuitive user prompting.
I'll be focusing now on putting together a new SLIK graphics API that will reside with ABC. I'm looking forward to playing with VIC over the winter season ahead.

Apologies upfront for necromancing this thread... it's been over a year from my last (serious) dabbling on this homebrew project.
Over the holidays, I re-visited this and updated the Awesome Boot Cartridge to work better with IEC directory handling and to automatically load & run a program if it's named AUTORUN.

I am slowly working on embedding an ABC module (extensible?) in this cartridge, namely a SLIK graphics API that is geared to provide software sprite and screen tile handling, with varying effects for size, color and speed, useful to the game programmer. I'm thinking of the cool Ultimem features and how they might get used in this, as an option. Ideas?

If you're feeling adventurous, visit its software development trunk. At minimum, you can download the cart (abc.a0) and sample disk image (abc.d64) for trial: xvic -memory all -cartA abc.a0 -10 abc.d64

The menu will attempt to *behave* with all the varying VIC memory expansions, and the Denial disks imaged prior should still work with this new cart image, too.

Hope you're going to be making use of this SLIK library yourself for some upcoming games, otherwise it seems a lot of trouble for you, especially as I don't recall much use of the old SSS (apart from myself) - it seems that people prefer to reinvent the wheel and role their own sprite libraries.

Yes, I have 2 videogaming projects in mind, plus 1 ludicrous-sized one. Building blocks, eh?