Vorticon

Would have loved to attend but sadly I'm on service that week...

I think @Ksarul is working on a modern version on the HRD.

I rarely use GOSUB. Using SUB instead allows for clearer and modular code that is easier to maintain.

Indeed. It does open up a lot of possibilities. Something similar I've done is when I created the graphics extensions on the Coleco Adam computer under CP/M using Turbo Pascal 3. I wrote a complete game in TP3 running entirely in bitmap mode, something usually unthinkable for the CP/M environment. The Adam had the same VDP as the TI.

Here's the (hopefully) final version of IMAGEDEMO which has an updated SAMS access utility which takes into account card size during initialization. Also it fixes the issue of the screen not returning to text mode after the bitmap mode has ended where I essentially save all the default values of the Pascal VDP registers (1-7) just prior to entering bitmap mode and restore them at the time of exit from bitmap mode. Setting just VR1 to text mode did not do it. Interestingly, in Classic 99, this was not needed and I thought that the OS simply reloaded the default values. That did not appear to be the case on real hardware where I got dropped into Graphics mode 1 along with some weird scrolling issues. Note to self: always test on real hardware before releasing anything developed under emulation SAMSUTIL.dsk

I was wondering how you managed to do that fantastic wavy background effect. So this game is strictly F18A dependent?

I applied my little scheme above to detect large capacity SAMS cards and it works. Classic99 QI399.065 2024-04-04 05-18-45.mp4 And here it is on real hardware with my 1mb card:

Well one way that would universally work would be to write a discordant value, say >0102 to the registers, then on a first pass test the MSB. If it passes, then test for the whole word. If it passes again then we have a card larger than 1 meg, otherwise it's smaller or equal. LI R1,>0102 MOV R1,@>401E CB R1,@>401E JNE NOCARD C R1,@>401E JNE SMCARD JMP LGCARD

I got the keyboard scanning routine to work in bitmap mode following @apersson850's method of relocating the keyboard buffers, but I also needed to restore the Pascal VR1 in low memory prior to exiting the routine as it seemed that the KSCAN routine was affecting it somehow. Otherwise I would get a garbage screen from an incorrectly set VR1. I don't have a clear explanation for this because the scanning routine copies the Pascal VRs to the RAMPAD and KSCAN is supposed to only use that area and should not affect the Pascal VR's. More often than not the p-system feels like it's finely balanced on the tip of a needle, and any unsanctioned activity like bitmap access will upset that balance and lead to unexpected behavior... Still waiting for that wig Anders...

True, but it's still problematic if one wants to support current existing hardware. There used to be an option to choose the size of the SAMS in Classic99, but it's now grayed out.

Not on my 1meg card. The detection failed just as in MAME with my original code. Are there different versions of the card?

It's actually a bug in my code. When reading the SAMS registers, a real SAMS card will only return the MSB (the page #) but not the LSB, whereas Classic 99 will return both as a word instead of a byte. MAME accurately emulates the SAMS behavior, including how the registers are read, which is why the program failed to detect the card. Same behavior on real hardware. Attached is a corrected version (replacing a C instruction by a CB one...) which fixes the issue. Sorry about that. SAMSUTIL.dsk

So here's my question about backing up the VDP RAM. The lower 4K will hold the standard character definitions which will get overwritten by a bitmap image. I did notice that even without manually restoring that area, somehow the definitions get restored when I return from bitmap. How is that possible? I knew about the keyboard buffer, but not the layout area. Is that the area which hold the key information you mention (120 bytes)? Also what about the Pascal VDP registers? You update them in your code after changing the standard VDP registers and I'm not too clear as to why. It's really important for me to understand fully how to do the bitmap switch back and forth while preserving as much function as possible, hence why I am peppering you with questions. You're the only person alive as far as I know with such in-depth knowledge of the system and I'm trying to leech as much of that priceless info as possible before it's too late! 😁 I also heard that you will be writing a series of articles on the p-system for the Chicago User Group newsletter. I'm looking forward to reading those.

It seemed like the safe thing to do as I frankly was not sure if there was something worth preserving. It was painless enough to do One question: Do I need to update the Pascal VDP registers vr1-7 in low memory when I switch to bitmap before calling the keyboard scan routine? Also your code mentions a keyboard layout area. What is that?

That is very cool. I wish there was a way to somehow redirect system input/output to the serial port. That way one could use a serial console for programming.

Quite possibly. Add it to the list of quirks and features of the p-system 😀

It's not. I have a standard 40 track TIFDC on my system.

The editor/filer, compiler, and assembler/linker are all separate disks. I have attached all the system disks you need for the p-system. The Editor/Compiler disk needs to be inserted in one of the drives in addition to SAMSUTIL if you want to view/edit or run files from the latter. ASM-LNK.DSK EDITOR-COM.dsk UCSD-UTI.DSK

OK everything works as it should now. The p-system was never intended to be used in bitmap mode, so credit goes to @apersson850 for figuring out how to coerce it to do so. Only issue is getting the keyboard key capture working while in bitmap mode. I'll have to study @apersson850's Turtle unit to see how he did it. Classic99 QI399.065 2024-03-31 21-37-37.mp4 SAMSUTIL.dsk

False alarm... I had forgotten to initialize the SIT... I'll post the complete demo in a day or two. Viger!

I'm trying to get bitmap mode working under the p-system. I'm using @apersson850's bitreserve scheme to reserve the VDP memory for bitmap mode, then I'm setting up all the appropriate VDP registers and loading the pattern descriptor table and the color table with the appropriate data from an image on disk. Prior to reserving the VDP memory, I am copying the entire VDP RAM to the SAMS card for later restoration. I verified with the Classic99 debugger that all the VDP registers are properly set up and that the VDP data has been loaded correctly, but it seems that the system is refusing to switch to bitmap mode after setting VR0 appropriately (value of 2) and I'm getting garbage on the screen although the colors appear correct. I did save the modified registers to the PME table (not sure if that is necessary). I have attached a disk image of the code. Execute BITRESERVE to run the demo. Note that it does not restore the system properly afterward. I haven't gotten to that yet. Incidentally, I am quite familiar with bitmap mode and I've done this many times outside of the p-system, so I think there is some special set up I am missing here under this environment. Classic99 QI399.065 2024-03-31 09-13-45.mp4 Here is the modified bitreserve code: and here is the imagedemo program which attempts to put a bitmap image on screen. The SAMS and VDP utilities associated with it are below as well. SAMS utilities: VDP utilities: SAMSUTIL.dsk

I tried >A000 and the system crashed every time. Since there is no way to tell where in upper memory an assembly program is residing, it seemed safe to avoid upper memory altogether. With all this needing to be done, particularly the invocation of the Filer and the copying of all the needed programs to the RAM disk, initial boot time must have been pretty lengthy (I'm estimating 2-3 minutes). A minor inconvenience I suppose in return for the benefits of a RAM disk. Seems to me you are best suited to make this project a reality since you've essentially done all this before. The only bit that would be different would be the windowing of the RAM access, and that's pretty straightforward to do as I've shown previously. What say you? 😁

It's not free, just not needed while running an assembly program, at least based on @apersson850's memory map. It will need to be restored prior to returning to the host program.

That seems to be the best path to me. The Mini Memory requirement in my view is probably the most universal solution to store the DSR. I have some serious reading to do...

Right. So I assume that rules out creating a DSR for it. Mind you I have zero understanding of how DSR's are set up and programmed outside of just a very superficial general concept. Is there a document somewhere that has a reasonable explanation of how one might create a DSR?