Beta Testers Needed

[8BitGuru]

Hi all,

I used to have an account here many moons ago but the credentials are lost to the mists of time, so I'm starting afresh.

And what better way to begin again than with a new product release for our favourite breadbin-shaped friendly computer. I hereby nervously present...

FAST-40 (Beta 1) - a new 40-column cartridge designed to be, well, fast.



It does seem to be fairly quick. I haven't yet benchmarked it against the other 40-column programs out there (and won't until I get to the 1.0 release) so I'm not making any definitive claims, but I will say that test programs I've run to time screen outputs seem to put FAST-40 slightly ahead of a stock C64.

On which note, before I finalise the build and declare it the 1.0 release, I'm looking for beta-testers to give it a bit of a kicking and see what sharp edges need sanding before allowing it loose into the world.

If you drop a line here I'll DM you a link to the Google Drive folder where the binary and readme live, so you can download it and test it in your emulator of choice and/or on real hardware if you have the means to burn the binary into a cartridge. I have a vague memory that one or more of the modern mega/super-carts might support image uploads, so if that's an option please do have a go. Equally, I know some of the multi-slot cart boards have the facility to swap RAM into BLK5 so you can load cartridge images that way.

I'm keeping the beta small as the day job doesn't leave a lot of free time for work on hobby projects and I don't want to get all stressed-out trying to keep up with lots of bug reports.

Any and all feedback will be greatly appreciated, and you'll get your name in the credits. Once we get to 1.0 I'll upload the whole package including full sourcecode to GitHub and make it available to all.

[tokra]

Is this the same as this?

https://web.archive.org/web/20151028171 ... age_8.html

which has been discussed here?

https://sleepingelephant.com/~sleeping/ ... php?t=6835

Either way, I'd for sure like to test-drive this and maybe compare it to FAT-40 and how it runs my "Green on Black"-conversions:

https://sleepingelephant.com/ipw-web/bu ... 89#p122189

[8BitGuru]

It is, and I'd completely forgotten there was a thread on it already. If a mod wants to move these posts to the end of it and nuke this thread, I have no objection!

I mothballed the project (and indeed all retro-related stuff I had going-on at the time) as Real Life CPU cycles went to 100% and I had zero free time for much of anything aside from the odd foray into WoW. Then a couple of years back my life settled down again and I unboxed FAST-40, discarding around 75% of what had been written and reworking the remainder. I then planned-out what needed to be done to finish it, created a frankly terrifying TO-DO list, and started to slowly tick things off.

And here we are, finished at last. What FAST-40 is today is not what it was back then, but then again neither am I.

[Wilson]

Respect for the tenacity!
This looks very cool! Would love to play with this as well if the offer is open.

[tokra]

You should also have a look at these programs for inspiration:

https://sleepingelephant.com/ipw-web/bu ... t=maxiedit

A 32x16 extension by VIctragic

https://sleepingelephant.com/ipw-web/bu ... t=maxiedit

My very own Maxi-/Uberedit for using a larger screen area.

https://sleepingelephant.com/ipw-web/bu ... 426#p96426

4ty by aeb, providing a flickering 40x25 editor with full color-support per char

I always liked the PET-emulation features of VIC-40 (aka FAT-40), but with your resolution of 40x24 the last line would be missing.

[MrSterlingBS]

Hi,

It would be an honor for me to make a small contribution to your great project.
I'd be happy to take a look at the code and the program and try out a few things.
Do you already have a link to the project?

BR
Sven

[8BitGuru]

I'm currently working on a bug reported by tokra where entering BASIC lines over 40 characters long triggers a syntax error (despite the code being built to handle 88-character lines ). If you LOAD a program with lines longer than 40 characters it's all good, so this is a screen-editor issue.

As is always the way, as soon as I started exploring why that was happening I found another bug in the character-insert logic.

I'm now certain that opening a beta-test phase was the right move, as these bits of code have been passing my tests for ages - which proves you can look at something for so long you just end up seeing what you want to see.

I'll fix these issues and then issue a new build in the next few days, adding any new volunteers at that point.

[8BitGuru]

And so...

Beta 2 is now available for testing.



If you already have a link, just download the package again to get the new build. If you volunteered but haven't yet received a link, check your PMs.

Changes in this build:

• Fixed a bug where entering long BASIC lines would sometimes lose the character in column #40, causing syntax errors (reported by tokra)
• Fixed a bug where data fed to the INPUT command included the prompt in the returned value and therefore broke it (reported by mathom)
• Fixed a bug where inserting a character into a long line would sometimes erroneously insert a blank line after it
• Fixed a bug where doing a character insert in column #40 erroneously placed the inserted [SPACE] into column #39
• Fixed a bug in the screen-scrolling logic which assumed that text buffer lines #23 and #24 would be contiguous in memory
• Fixed a bug where RUNSTOP+RESTORE didn't reset the default text colour and character-case
• Added a simple CPU register display to the BRK handler to help debug JiffyDOS crash (reported by mathom)
• Added an alternate build option to do LOAD"$",8 / LIST on SHIFT+RUNSTOP
• Tweaked the PAL/NTSC startup test to save the result for RUNSTOP+RESTORE and thereby avoid repeated re-tests
• Tweaked the cursor blink phase timings to help cursor visibility during rapid/repeated movement (reported by mathom)

For this second beta, you'll now see the following simple register dump before the READY prompt if the code finds a way to hit a BRK instruction (which it should never do, and will almost certainly be fatal if it does). Please forward a screenshot or transcript to me with a brief description of your setup and what you were doing when it hit. So far the only crash report is some sort of incompatibility with JiffyDOS, so hopefully this will help me diagnose that.



Many thanks for the testing so far - it's been emotional.

[8BitGuru]

Beta 2A just dropped, which fixes a bug in character insert/delete which I inadvertently introduced as a side-effect of the cursor blink phase timer tweak.

[8BitGuru]

And so...

Beta 3 is now available for testers to play with. Please download from the link you already have.

Changes in this build:

• Includes the Beta 2A fix where Stack poisoning caused mayhem in the insert and delete key handlers (reported by tokra@denial)
• Fixed a bug where deleting a character from column #1 replaced the character in column #39 on the previous line instead of column #40
• Fixed a bug where deleting a character from column #1 of an unlinked line produced an unwanted side-effect on the previous line
• Fixed a bug where the screen-scroll CTRL-delay code intermittently failed to execute (reported by tokra@denial)

Based on tokra's reports it looks like the issues in Beta 2 were mostly edge-cases, typically caused by off-by-one index errors rather than anything being fundamentally b0rked.

If anyone has any insight into the JiffyDOS Kernal (or maybe there's an online resource somewhere?) I'm keen to explore what might be causing the hard crash that mathom sees. I'm wondering if something in the modified ROM is in a slightly different position and FAST-40 is jumping into a data block or offset instruction operand of zero (the BRK opcode)? I'd like to add a check to identify when JiffyDOS is installed and fix the problem.

Anyway, I'll let Beta 3 settle and see if any further bugs creep out. Many thanks to everyone who is helping me make FAST-40 better by kicking it around.

[8BitGuru]

After I'd packaged Beta 3 last night I spent a happy hour doing that benchmark I mentioned. We're not officially at v1.0 yet but the code is unlikely to change much between now and that point, so I thought I'd have a play with the competition. Here's the result.



All six need a minimum of 8K in BLK1, but only FAST-40 will use RAM if it's present in BLK0 to give the whole 8K (or 16K, or 24K) to BASIC.

All five competitors have issues - some trivial, some serious:

• None support full 88-character lines
• None handle the CTRL-delay properly, although I give Screen-40 a pass on this as I quite liked having CTRL do a hold instead of a delay
• Three of them exhibit anomalies in their display technique, with Vic 40 Scherm being completely broken

Overall, FAST-40 yields the most RAM to BASIC and PRINTs 4000 dots (full-stops) to the screen second-fastest; Screen-40 is 10 ticks quicker but occupies more memory and breaks on lines longer than 80 characters.

Three generate 40x25 displays, whereas FAST-40 is in the 40x24 camp. The extra line is useful if you're trying to run a PET program without modification (which may expect 25 lines) but each have their problems, and they take (roughly) twice the time of the others to update the screen when performing large character-block movements or when scrolling the screen.

Screen-40 is admirably tiny, and I think that's because it's using the stock Character Generator ROM as its glyph source. It looks like it does some sort of pre-processing or on-the-fly modification to the pixel data in order to shrink it, which is devilishly clever but results in 'chopped' characters which are particularly noticeable when displaying graphics.

Overall I think FAST-40 stands-up well against its peers. In my opinion Screen-40 is its closest functional competitor, and being a program it can be loaded and used alongside a utility cartridge whereas FAST-40 cannot. However, FAST-40 benefits by stealing less RAM from BASIC, and produces a somewhat nicer display that supports full 88-character lines.

As a callow youth in the early 80s I used Super Screen and marvelled at the nameless gods who had created it. I still do, but now at last in their mighty company I do not feel ashamed.

[tokra]

Of the original pack I think FAT-40 (aka VIC-40) is the best yet. It provides 40x25, emulates the PET-video-RAM at 32768 ($8000) so you can POKE directly to it and even emulates the PET sound-hack that was done through its user port and later supported by Commodore as well. Some time ago I "ocr"-ed and reformatted the manual from Ahoy-Magazine to HTML, see here:

https://www.tokra.de/vic/greenonblack2/ ... anual.html

Also, CTRL does not freeze/crash the VIC-20, instead it has multiple features, quoting from the manual above:

"One noticeable difference is the presence of a real control key. The CTRL key used to change colors; now it will cause an indefinite pause until either SHIFT key gets pressed. To use the CTRL key to change colors or to turn on/off reverse field, SHIFT-CTRL must now be used. This feature is designed as an aid when LISTing programs, or making the computer wait until you are ready."

Once you have FAST-40 ready it should be possible to extend it to 40x25 by providing the 25th line dynamically. I did something similar on a PET recently. You'd have to arrange the memory so that the character definitions go into the $2000-area but copy them around at the right time during display, so the VIC always sees them in the $1000-$1fff area. This way you may also get 8x8 colour-resolution instead of 8x16. This would lead to a slowdown of course, but since FAST-40 is fast to begin with, it may not matter that much

Does FAST-40 provide POKEable access to its (virtual) video-RAM already?

[8BitGuru]

Well that [FAT|VIC]-40 CTRL-key functionality is cool - I probably hit every key except SHIFT trying to 'unfreeze' it.

Your points about PET emulation are interesting, but FAST-40 wasn't really built to be a PET emulator or to provide an API for programmers to play with the high-res screen. The objective was to provide more text real-estate, and maybe get some Scott Adams or Infocom adventures working with it.

I kinda like the idea of maybe providing a simple BASIC command like:

Code: Select all

PLOT x,y,c

This would let BASIC hit the bitmap, but intercepting PEEK and POKE to try to provide a facade of screen addressability doesn't appeal.

I'm not planning on doing a 25-line version of FAST-40, though others may want to take the sourcecode and create a variant. The original display logic from VIC++ (the long-abandoned precursor project from which FAST-40 emerged) does exactly that, using a raster split to re-arrange things on-the-fly and generate the extra line, but a key design principle of FAST-40 is that screen-scrolling is done by rolling the 12-row character matrix (and a couple of associated pointer tables) so expensive bitmap copies and/or redraws rarely have to be done.

I experimented very early on with keeping that 25th (or 13th if you prefer) matrix line, but couldn't find an efficient way to integrate it without needing to do a bitmap copy after (at least) every third line during scrolling. The resultant performance impact was too much to bear - every line of code in FAST-40 has been written with the single-minded mantra "make it as fast as you know how", and that extra line just kept hurting.

I'll think about PLOT, but I only have 114 bytes free in the ROM at this point so it might have to wait until I've got a handle on the JiffyDOS problem and can remove the BRK-handler code that's in there to help me diagnose it.

[tokra]

I didn't actually mean hires-plot but just poking to the 40-column screen-RAM. So on a usually VIC-20 with 8K expansion you do POKE 4096,1 and an "A" is shown at the top left corner. You must have some shadow-screen-RAM for your 40 column-screen I suppose, so there should be a way to display that "A" in the top left corner (or anywhere on the 40-column screen) as well, this would also make it easier to adapt C64/PET-programs that write to the screen like this.

[8BitGuru]

Ah I see. Interesting.

FAST-40 uses a 960-byte non-contiguous text buffer to handle the actual character code storage for what is then rendered to the bitmap. That buffer is either tucked into the top of BLK0 or the top of whichever highest of BLK1/2/3 has RAM in it. The vectored CHROUT replacement code uses indirection to address the text buffer in order to set/read character bytes in it, and then calls the rendering engine to update the bitmap.

So I could intercept PEEK/POKE to the 4096-5055 ($1000-$13BF) range and map the given address to the right spot in the text buffer, and then either return the byte for PEEK or call into CHROUT for POKE which would set the byte and do the bitmap update.

You'd still need to do a bunch of work to programs which did screen updates via PEEK/POKE because they'd be working to a 22x23 matrix, so a POKE to 4118 for example would put a character at R1:C23 rather than R2:C1. Access to Colour RAM at 37888 would work unchanged but of course at only half the usual R:C resolution.

Is there a demand for this? It would be interesting to implement (as well as the PLOT command) but is anyone ever likely to make use of it?