Vorticon

Sorry I did not get emails. Might have gone to the junk folder. Atlantis is on my list already when I get some time to update. Good game.

Is there a way to pass arrays of different sizes to a single generic array parameter in a procedure call? Right now I have to create a Type declaration for an array of a specific size, declare an array of that type, and use it as a parameter in a procedure. The problem is that if I have a need for arrays of different sizes that can use the same procedure, I'll have to make Type declarations for each one as well as additional procedures to accept these new types. Obviously not a solution...

Tested on real hardware. Works. 20240323_051644.mp4

Any news from Sparky?

So based on what @Lee Stewart said above, it seems I was testing the memory contents wrong. I was writing to the test page and reading it back, and apparently that will always be equal regardless of whether the actual page exists or not. Using what Lee did where I write a value to the initialized memory location, change the page then test of equality did the trick. Not necessarily evident by any means particularly when Harrison was doing what I was originally doing myself. Here's the now working source. It's so fast that I'm not bothering with skipping testing at the 128K boundaries which would complicate things and rather just going through all the pages sequentially. .func samssize ;returns the number of pages available ;usage: sizeint := samssize .ref pcodeon,pcodoff,procret mov r11,@procret bl @pcodoff li r12,1e00h ;cru address of sams card sbo 0 ;turn on card sbo 1 ;turn mapping on li r4,16 ;page counter. skip over first 16 pages li r1,15 ;page/bank register value mov @2000h,r3 ;save contents of test memory location li r2,0ffffh ;test value mov r2,@2000h ;low memory location used for testing incpage ai r1,1 ;add page/bank starting at page >10 bank 0 swpb r1 mov r1,@4004h ;map address >2000 to page/bank c r2,@2000h ;did it write correctly? jeq endpage ;new page should not equal initial value swpb r1 clr @2000h inc r4 ;increment page counter jmp incpage ;try next page endpage li r1,0200h ;restore original mapping mov r1,@4004h mov r3,@2000h ;restore contents of test memory location sbz 1 ;turn mapping off sbz 0 ;turn off sams card mov r4,*r10 ;return page counter bl @pcodeon mov @procret,r11 b *r11

But you are exiting the routine if the page is not equal to >994A. I'm confused

I simplified my code a little, but still the same issue where any bank/page will work regardless of the size of the SAMS as verified by the debugger. I will have to try that on real hardware again tonight. .func samssize ;returns the number of pages available ;usage: sizeint := samssize .ref pcodeon,pcodoff,procret mov r11,@procret bl @pcodoff li r12,1e00h ;cru address of sams card sbo 0 ;turn on card clr r4 ;page counter li r1,15 ;page/bank register value li r2,0ffffh ;test value incpage ai r1,1 ;add page/bank starting at page >10 bank 0 swpb r1 mov r1,@4004h ;map address >2000 to page/bank sbo 1 ;turn on the mapper mov r2,@2000h ;write test value to >2000 c r2,@2000h ;did it write correctly? jne endpage swpb r1 clr @2000h inc r4 ;increment page counter sbz 1 ;turn off the mapper jmp incpage ;try next page endpage li r1,0200h ;restore original mapping mov r1,@4004h sbz 0 ;turn off sams card dec r4 mov r4,*r10 ;return page counter bl @pcodeon mov @procret,r11 b *r11

I don't understand the part where you check the contents of the write. You initially write a test value to >E000, turn on the card, load >401C with the page you want to test, turn off the card, then do a compare between the original test value in R2 and the contents of >E000. You don't have mapping on, so writing to >E000 really is just writing to the original location and not the test page. And why are you turning the card off before the compare operation? What am I missing?

With the card initialization and detection sorted out, next I wrote a routine to find out the size of the card (number of pages). Well guess what? It's not working either 😭. It appears that the assigned register (here >4004 pointing to >2000 in low memory) will dutifully write to that memory location regardless of the value of the page/bank value assigned to it. That can't be right, but I checked with the debugger and it seems that way. The way I'm finding out the number of available pages is by assigning an incremental page/bank value to register >4004, writing a value in r2 (>FFFF) to >2000, then comparing >2000 to R2 again. If it matches, then the page is OK and we continue, otherwise we have reached the end of the available pages. That's how Harrison did it. .func samssize ;returns the number of pages available ;usage: sizeint := samssize .ref pcodeon,pcodoff,procret mov r11,@procret bl @pcodoff li r12,1e00h ;cru address of sams card sbo 0 ;turn on card clr r4 ;page counter li r1,0ffffh ;page/bank register value li r2,0ffffh ;test value mov @2000h,r5 ;save contents of the >2000 low memory address sbo 1 ;turn on mapper incpage ai r1,1 ;add page/bank starting at 0/0 swpb r1 mov r1,@4004h ;map address >2000 to page/bank mov r2,@2000h ;write test value to >2000 c r2,@2000h ;did it write correctly? jne endpage swpb r1 clr @2000h inc r4 ;if yes then increment page counter jmp incpage ;try next page endpage sbz 1 ;disable mapper mov r5,@2000h ;restore original contents of >2000 sbz 0 ;turn off sams card dec r4 mov r4,*r10 ;return page counter bl @pcodeon mov @procret,r11 b *r11

Very nice indeed! Saves you from buying the expensive photosensitive PCB's. That said, I'm not sure this is much faster than traditional light etching although it certainly gives your neat machine something to do 😄

Thank you for that great explanation. Now I fully get the issue. Harrison complained in his article about the lack of proper documentation for the AMS card and he had to cobble together an understanding of its functionality through a combination of source code evaluation and asking others like Rich Gilbertson and Lew King. Besides, anything beyond 1 meg was probably not on anyone's horizon back in the day, and frankly even today there is hardly anything out there that requires more than that except perhaps the wonderful Stevie editor by @retroclouds. Not sure I understand that. Wouldn't that comparison happen on the full word of the SAMS register? Edit: figured it out with @FALCOR4's document below. (>1380 - >1340 - 6) / 2 = 29! You might be right unless I'm missing something. I'll test it out tonight.

We I'll be damned... When I tried it on real hardware it worked perfectly! Something must be off with the Classic 99 emulation of the pcode card or SAMS card. @Tursi any thoughts? I'll post a disk image tomorrow to try on MAME.

I managed to find on Amazon a new hardcover copy of Big Computer Games for 30 bucks, so I snapped it! I'm a sucker for old computer books from the 80's in particular.

I'm not too clear on this. Can you please elaborate a little more?

I need to get the card working first though. I still don't know what's going on here. I'm going to test it out on real hardware tonight and see if it makes any difference (probably not).

Do I need to disable interrupts when accessing the SAMS card? Also when you say it's working for you, how are you testing the code? As to finding out where it's crashing, I wouldn't know where to even start looking since the code could be stashed anywhere by the system. All I can see is that only SAMS registers 0 to A are being initialized for some reason. Edit: I inserted an infinite loop right after the JLT NXTPAGE statement and it never gets to it, which makes sense since not all the SAMS registers are being initialized, so the issue must be happening when SAMS register >401B gets accessed, which is referencing the >B000 memory block. Something tells me I'm overwriting some system variable somehow, but that should not be possible since the mapper was not turned on.

I am saving and restoring R12 so I don't think that's the issue. And since I am not using R8-R15, there is no need to save them either. The behavior is odd...

Moving on to my next project: develop a set of utilities of SAMS card access within the pcode system. First test: initialize the card and verify that it is present. I'm plagiarizing Bruce Harrison's code as published in Micropendium (sep/oct 96), and it's not working. I'm not sure if the pcode card needs to be deactivated prior to SAMS access but I tried it both ways: if the pcode card remains active, the system just hangs, whereas if it is inactive I get a black screen and then the system hangs (more interesting to look at I suppose). In looking at the debugger, only SAMS registers 0 to A are being initialized, so something is fishy here. ;routines for sams card access ;walid maalouli ;march 2024 .func samsinit ;initialize the sams card and verify card is present ;returns 0 for absent and 1 for present ;adapted from routine by bruce harrison (rip) ;usage: status := samsinit .def procret,pmeret,pcodeon,pcodoff mov r11,@procret bl @pcodoff li r12,1e00h ;cru address of sams card sbo 0 ;turn card on li r1,0feffh li r0,4000h ;start address of sams registers nxtpage ai r1,0101h ;increment page number starting at 0 mov r1,*r0+ ;load page number into sams register ci r0,4020h ;beyond last register (401eh)? jlt nxtpage c r1,@401eh ;if match then card present jne nocard li r2,1 jmp endinit nocard clr r2 endinit mov r2,*r10 ;place card indicator on return stack sbz 0 ;turn sams card off bl @pcodeon mov @procret,r11 b *r11 pcodeon li r12,1f00h ;activate the pcode card sbo 0 mov @pmeret,r12 ;restore the pme pointer b *r11 pcodoff mov r12,@pmeret ;save the pme pointer li r12,1f00h ;deactivate the pcode card sbz 0 b *r11 pmeret .word procret .word .end

Clever! Thanks for the explanation. It's a rather obtuse way of doing things, so there had better be a good reason to do so. In my world clarity of code trumps maximum efficiency in most situations.

No s***t... 😁 Care to explain?

That would be awesome! VDP interrupt, PIO input, joystick activity and key presses are definitely top candidates. Some kind of interrupt detection around the reception of a character on the RS232 port could actually be quite useful in order to wake up a pended task that reads data from the serial port. I'm thinking of my Heathkit robot project in particular here. We've waited 43 years, so I don't think there is any rush

I thought Tursi took over hosting that page. You might be looking at a deprecated page.

I realized that David Ahl's books (Basic Computer Games, More Basic Computer Games and Big Computer Games) are missing from the Book Archive (https://harmlesslion.com/tibooks/). Any chance these could be added?

Now that I got my brain properly wrapped around the TI's implementation of concurrency, I was able to create a version that actually prints the messages sequentially as expected. While the task itself is simplistic here, it could obviously be made much more interesting, such as cycling between different sensor inputs etc... using global parameters. There may be potential there. program semtest; var i : integer; pid1, pid2, pid3 : processid; console, sem : semaphore; procedure conwrite(outiam : integer; outmsg : string); begin wait(console); writeln('I am ', outiam, ' and my message is ', outmsg); signal(console); end; process msgwriter(whoiam : integer; mymsg : string); begin repeat conwrite(whoiam, mymsg); wait(sem); until false; end; begin seminit(console, 1); seminit(sem, 0); start(msgwriter(0, 'Shakespeare'), pid1, 900, -1); start(msgwriter(1, 'monkey'), pid2, 900, -1); start(msgwriter(2, 'typewriter'), pid3, 900, -1); repeat for i := 1 to 3 do signal(sem); until false; end. SEMTEST.mp4

Can I bribe you in any way to make ATTACH work? 😁