Asmusr

Sorry, after reading TheBF's post, I realize it's of course VSMW that should be used in my post above. Don't know if it's part of the standard E/A routines?

VSMW is looping for you. All you need is: CLR R0 LI R1,>2000 LI R2,768 BLWP @VSMW The problem is there are many coding styles and ways to pass parameters in assembly. I even find it difficult to reuse my own routines from one game to the next.

You need to check if the name table at >0000 and the pattern table at >2000 contain the expected data.

Just a stupid mistake. Try now.

Looks like I broke the TIPI emulation. I will fix it later tonight.

Right, so he could implement the same solution as the F18A, which is to mask to 3 bits unless the 80 columns mode is selected, in which case writes to registers >= 8 are ignored.

Please, I'm not talking about what you should do but which registers @speccery would have to implement to support 80 columns. You're enabling the mouse and setting a bit related to the VRAM organisation, but speccery can ignore that if he supports neither. And then you're setting some blinking options that he probably doesn't want to support either. I think he still only needs to support the mode bit in VR0.

I have released a new version of JS99er with some bugfixes related to the TIPI: there was a problem when you enabled and disabled the emulation, and the CPU is now suspended until the websocket is running. I have managed to load programs from the TIPI, but when I try to save a simple BASIC program (SAVE TIPI.BAS.HELLO) I get an I/O ERROR 66. What am I doing wrong? And what is the correct way to shut down QEMU? Thanks.

I forgot that the F18A firmware 1.8 and above ignores writes to VR8 and above if 80 columns mode is selected and it's not unlocked. So that's why it doesn't hurt to write to VR8-VR15 on the F18A. On the V9938 those regs have the following meaning: VR8: Mouse, light pen, sprite disable, etc VR9: Vertical line count and other output related bits VR10: Color table high VR11: Sprite attribute table high VR12: Text and background blink color VR13: Blinking period register VR14: VRAM access base register VR15: Status register pointer To implement a simple 80 column x 24 row mode, I think all of these can be ignored. The only issue is if software uses VR15 to set status register 1 in order to detect the V9938 or F18A, then that would have to be implemented.

Are you detecting if an V9938/F18A is present or are you setting these registers blindfolded? I think in addition to the bit in VR0 @speccery might have to support detection.

VR10 and VR11 on the F18A are for setting name table and color table of tile layer 2. They are not needed to set 80 color mode. If the F18A is locked you will address VR2 and VR3 instead.

What is the reason for setting all those registers? I would have answered that he only needed to support one extra bit of register 0 (bit weight >04).

But finally it works!

I think it takes even longer to set up (90 minutes and counting...) with the tipi image than it did with the generic image I used before. Isn't it possible to pre-install the dependencies on the image?

I have added a map. Press M to see it, press Up to close it. I'm not sure it will stay as easy as that that. Maybe you will have to find the map first? Maybe it should only show areas you have visited? raycaster.dsk raycaster.rpk raycaster8.bin

I don't know about the hub, but it's a fiber alright. We could also get 1000 Mbps if we paid for it. But actually the change from our old ~11 Mbps ADSL wasn't that noticeable, except when I upload to YouTube.

Here's mine

No the CORS policy doesn't seem to apply to websockets.

Ahh, so that's what it's for. But I always run from https://js99er.net unless I'm changing the emulator.

You probably noticed that I already deployed your changes to https://js99er.net, but I still haven't been able to get the RPi side up and running myself. My QEMU is running with this configuration, and all the services on the RPi appear to be running except the TIPI boot service: qemu-system-arm -kernel kernel-qemu-4.19.50-buster -dtb versatile-pb-buster.dtb -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -drive "file=2020-02-13-raspbian-buster.img,index=0,media=disk,format=raw" -device e1000,netdev=net0 -netdev user,id=net0,hostfwd=tcp::9901-:9901 In JS99er it seems to be making a websocket connection (at least it's different from not running QEMU), but it's closing after a short time, and nothing happens. Do you have any ideas hot to troubleshoot this?

Can you make a pull request for me to get your changes?

You can reset and lock the F18A with: LI R0,>3280 BL @VWTR Did you try you code in js99er?

Yes, you can use sprites in text mode if the F18A is unlocked.

Did you try to produce a list file and look at the string in that?

Or this, Marble Madness, in 3bpp mode. Requires 699 characters.