Absolutely, and it gets better: I missed the conditional operators specific to VTL02: [ and ]. At first just replacing * with [ in line 55, 80 and 120 didn't make any difference on the run time. But then also simplifying line 55 from
to
won a few seconds, for a new total of 1m14.9s and VTL and taking the lead.

Yeah, I spent six bytes for a little check inside the multiply loop to finish early for small left-factors like 0 and 1, so it's probably not much slower than [ and ] for your use case. Large left-factors suffer a tiny penalty (128 additional cycles worst case), but I felt that it was a reasonable trade-off.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Good news! I just got VTL02 (Mike's version C) working on Daryl's SBC-4 (10MHz W65C816).

I am somewhat surprised that the prime-number shootout code ran in just over 3 seconds.

Thank you, Mike!


Code is here: repo at Gitlab (no microsoft for me).

Porting notes:

It appears that the main stumbling block to porting is VTL02's zero page usage. As I understand, it needs a solid block of 128 bytes at $80, and the routine called simple must be matched. Mike has instructions for relocating zero-page block.

May I suggest making the code slightly more portable:

One must still adjust simple, but it makes the job a little easier, and clearly communicates the need for all the variables to stay together as a block (the labeling led me to think otherwise until I wised up)...

The difference in assembler syntaxes is infuriating. Luckily there was only a handful of replacements for low and high address syntax.

Overall, porting is trivial. It took me a few hours to rediscover that the OS uses top of zero page, tracing weird stack corruption that ensued. It took me longer than it should have to notice that I can't just move the vars in $F0-$FF down arbitrarily (more strange bugs). If I was at the top of my game I could've done this in 10 minutes.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Congratulations! I have an optimized NMOS version C (somewhere) that has identical features but is a bit smaller and faster, but the death of my desktop PC and my huge backlog of distractions has prevented me from debugging it properly ... I know it was still buggy when I stalled on it, but it sure was a tight little 8-bit ball of twine. A 16-bit '802/'816 version would definitely be faster, but I don't see it being any smaller, due to all of the annoying REP# and SEP# housekeeping. I would likely do a 'c02 version if I found the time, but a native 16-bit version isn't likely, at least not from me ... the '816 just doesn't really flip my switch.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

I may psych myself into doing an '816 port. I think the trick with '816 is to keep the indices in 8-bit mode, and only diddle the accumulator size here. The big win is the memory move takes almost no code, and 16-bit variable access and arithmetic, of course. I suspect it will be smaller as well as faster. I am actually running in '816 mode, with 8-bit registers, so experimenting should be fairly simple.

The '816 allows the zero page to be anywhere in the low 64K bank... This begs for VTL-OS, with multiple VTL-02 programs, each with its own zpage and data... These can be pre-emptively switched, or coersively multitasked via the interpreter loop.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

The code at skp2: deals directly with deleting and inserting program lines, and has been 151 bytes of NMOS for a long time. I'll nominate you for employee of the month if you can figure out a way to make it more than a few bytes smaller on any 65xx.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

I re-coded most of the operators with a 16-bit accumulator, which shaved off about 100 bytes. It's true, the 4-byte hit for switching into and out of 16-bit mode adds up. I think I can temporarily use Y for character dispatch and stay in 16-bit mode, saving 4 bytes per operator.

I choked on the really clever < = > code, it is all tangled there, in the final case that handles all three. I think I can subtract the two values in advance of the final 3 operators, handle the = case, then rotate the sign bit to low. For < I can AND 1 (negative is true). For > I need to flip the result. I didn't quite understand how you did all 3 in something like 10 bytes and went to bed frustrated. If you have a minute, a quick lesson on efficiently converting positive and negative values to 0 and 1 would be helpful.

I was also considering constructing a jump table for operator dispatch, for characters $20-$3F. That's 64 bytes to cover almost all cases, much faster and probably close to the size of the current dispatcher. Actually $20-$2F contain most operators, especially if < = > are handled separately as a last resort.

As for moving memory, the MVP instruction should do most of it, and I am looking to recover 100+ bytes right there.

I have a feeling that the '816 version should fit into 768 bytes!

Do you have the original 6800 code perchance? All I could find was a bitmap of a printout that was barely comprehensible. Not that my 6800-foo is any good.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Bruce helped me with that, so it's a bit above my pay grade to help you completely understand it. The corresponding part from version A is all mine, but it has been over nine years since I visited that, so ...


I found this in my old stuff. My Altair to SWTPC port came before the 6502 version, so it doesn't have the bit-wise operators or THEN/ELSE/PEEK/POKE. I'm not 100% sure that this one is totally bug-free, because I was optimizing for size and juggling different revisions before I abandoned it (looks like I got it down to 709 bytes), but here ya go ...



Carl D. Warren's 6809 Cookbook (or at least the old paper-and-ink edition I have) contains a full listing of a rather crude 8/16-bit port, but I don't know how available or useful that would be to you.

Enjoy, and happy coding!

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

I've been puttering around with a 65c02 version ... let's call it VTLC02. I've taken advantage of new techniques I've learned in the last ten years and the "fancy new" instructions and addressing modes of the 'c02 to shave a couple dozen bytes off of VTL02C, but it's still buggy, and I have limited spare time as usual. I'll post it when I get it working in the Kowalski simulator, since I've been trying to move my 65xx stuff into a more generic environment. A laptop crash here caused a big setback, but I'm slowly swimming back upstream.

Question for the interested members: Should I see if I can squeeze another feature like multi-statement lines or a faster run-time line FINDer with the space that I saved switching to CMOS? I want backward software compatibility and < 1024 ROMable bytes for the entire IDE, but the rest is still undecided. Error handling beyond a "?" message is almost certainly off the table, though ...

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

A speedup from finding lines faster sounds good!

Well, I have reached a save point. Attached is a 971 byte Kowalski version of VTLC02 that is smaller and faster than VTL02C, with all the same features. The Apple //e version would be several bytes shorter for not having to deal with the Windoze line feed nonsense, but I'm not including it for now. I believe I can make it even smaller and faster, but I'm going to pause here and deal with some other items on my plate. The structure is becoming less and less "modular", but who needs all that C.S. pinky-finger-out stuff when there's fat to be trimmed, right?

Please let me know if you have any comments, suggestions or bug reports.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Now at 970 bytes and hosted on GitHub. I mean it this time ... I need to take care of a ton of unrelated stuff for a while ...

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Great!