tsom

Cool! Builds and runs now! Now to have a play

FWIW, I replaced #include <endian.h> with the below (that I found) and it builds. May need to be tweaked? #if defined(__APPLE__) #include <libkern/OSByteOrder.h> #define htobe16(x) OSSwapHostToBigInt16(x) #define htole16(x) OSSwapHostToLittleInt16(x) #define be16toh(x) OSSwapBigToHostInt16(x) #define le16toh(x) OSSwapLittleToHostInt16(x) #define htobe32(x) OSSwapHostToBigInt32(x) #define htole32(x) OSSwapHostToLittleInt32(x) #define be32toh(x) OSSwapBigToHostInt32(x) #define le32toh(x) OSSwapLittleToHostInt32(x) #define htobe64(x) OSSwapHostToBigInt64(x) #define htole64(x) OSSwapHostToLittleInt64(x) #define be64toh(x) OSSwapBigToHostInt64(x) #define le64toh(x) OSSwapLittleToHostInt64(x) #elif defined(__linux__) #include <sys/types.h> #endif

I tried changing the line to: #include <machine/endian.c> on the advice I found looking up the issue, but that now gives a bunch of errors like: disasm.c:1275:17: error: call to undeclared function 'le16toh'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] int target = le16toh(*(uint16_t *)&load[2]);

Just tried building this on MacOS. Pulled down the repo, and executing the `make` command results in: ```  ~/Developer/Atari/atari_8bit_utils/disasm/ [main] make cc -g -O0 -W -Wall -c disasm.c disasm.c:13:10: fatal error: 'endian.h' file not found #include <endian.h> ^~~~~~~~~~ 1 error generated. make: *** [disasm.o] Error 1 ```

Does anyone know if the source code to Caverns of Mars was ever released/posted? I’m curious to be able to have a peek at how it was done. I’ve searched but to no avail. Thanks!

Figured it out. These lines: GAME JSR SIOINV ;Init sounds LDA # <DISP+80 STA LO LDA # >DISP+80 STA LO+1 Need to be: GAME JSR SIOINV ;Init sounds LDA # <(DISP+80) STA LO LDA # >(DISP+80) STA LO+1 ATASM was doing taking the low and high bytes of the display memory and adding 80 to each - instead of adding 80 to the address of the display memory THEN taking the high/low bytes. Adding the parenthesis enforces the operator preference. Assembled difference: 110 2803 A9 50 LDA # <DISP+80 111 2805 85 C1 STA LO 112 2807 A9 6D LDA # >DISP+80 113 2809 85 C2 STA LO+1 110 2803 A9 50 LDA # <(DISP+80) 111 2805 85 C1 STA LO 112 2807 A9 1D LDA # >(DISP+80) 113 2809 85 C2 STA LO+1

That's what I meant. I used that disk image, extracted the bonk.m65 file and assembled it with ATASM and was getting the same problems. It may assemble correctly, but it still has problems.

Very interesting!

I just extracted that version and assembled it. And while there's an issue with ATASCII to ASCII that I have to deal with, it still look like it's not seeing collisions with anything but walls and enemy's. Love a good mystery!

Just for fun, I tried assembling the game BONK from ANALOG. (Source code here: https://github.com/jtsom/AnalogSourceCode/blob/master/Bonk.asm or https://ksquiggle.neocities.org/asmgames/bonk) I assembles just fine using ATASM, and launches and starts running. However, when the game is run, your player does not interact with the game, except for the walls (cannot pick up the diamonds, knock down the colored walls, etc.) An enemy or wall collision is detected however. I have a copy of the game from, I believe, the Homesoft collection, and that one works just fine. This is running in the Atari800MacX emulator. I see the part of the code where collisions are checked, and it looks like it should be working, but I'm not sure how to debug this. Thoughts? Thanks!

Yep. All good now: ``` pi@tnfs:~ $ systemctl status tnfsd ● tnfsd.service - TNFS Server Loaded: loaded (/etc/systemd/system/tnfsd.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2023-02-08 08:47:19 EST; 2h 7min ago Main PID: 29144 (tnfsd) Tasks: 1 (limit: 2178) CGroup: /system.slice/tnfsd.service └─29144 /usr/local/sbin/tnfsd /tnfs Feb 08 08:47:19 tnfs systemd[1]: Started TNFS Server. Feb 08 08:47:19 tnfs tnfsd[29144]: setroot real path: /tnfs Feb 08 08:47:19 tnfs tnfsd[29144]: Starting tnfsd version 23.0207.1 using root directory "/tnfs" ```

Well, the script didn't do the update, as it assumes the code was already downloaded. I ended up doing the steps in the script manually, after cloning the repo and was able to update my local server.

I installed my TNFS server onto my raspberry pi using the packaged image posted on here, somewhere (I forget who had set it up). It has a "tnfsupd" script that looks to go out to Github and update itself. It looks like it successfully did, but I'm not sure how to tell if it's the latest version: ``` pi@tnfs:~ $ sudo tnfsupd Stopping TNFSD Updating TNFSD fom GitHub Restarting TNFSD pi@tnfs:~ $ tnfsd -v Starting tnfsd version 20.1115.2 using root directory "-v" Unable to bind ``` My systemd setup has this: ``` [Service] User=tnfs Group=tnfs ExecStart=/usr/local/sbin/tnfsd /tnfs ``` I assume it's ok? (it's also not visible outside my network, so it may be a moot point) Also, looking at the GitHub link, the releases linked there look very old Just want to make sure the latest version is available. Thanks!

Put this as a tasks.json file in the same folder as your code and it will give you build tasks for MADS and also Atasm. Just SHIFT-Ctrl-B and choose which assembler you want. { // See https://go.microsoft.com/fwlink/?LinkId=733558 // for the documentation about the tasks.json format // tasks and problem matcher to compile Atari sources in the Mac/65 format "version": "2.0.0", "tasks": [ { "label": "Build - ATASM", "type": "shell", "command": "atasm", "args": [ "${relativeFile}", "-mae", "-Iincludes", "-IUtility", "-o${fileBasenameNoExtension}.com" ], "group": "build", "presentation": { // Reveal the output only if unrecognized errors occur. "reveal": "always" }, "problemMatcher": { "owner": "atasm", "fileLocation": [ "relative", "${workspaceFolder}" ], "pattern": [ { "regexp": "^In (.*),\\sline\\s(\\d+)--$", "file": 1, "line": 2, }, { "regexp": "^\\s(Error|Warning):\\s(.*)$", "severity": 1, "message": 2 } ] } }, { "label": "Build - MADS", "type": "shell", "command": "mads", "args": [ "${fileBasename}", "-l", "-o:${fileBasenameNoExtension}.com" ], "group": "build", "presentation": { // Reveal the output only if unrecognized errors occur. "reveal": "always" }, "problemMatcher": { "owner": "MADS", "fileLocation": [ "relative", "${workspaceFolder}" ], "pattern": [ { "regexp": "^(.*)\\s\\((\\d*)\\)\\s(ERROR|WARNING):\\s(.*)$", "file": 1, "line": 2, "severity": 3, "message": 4, } ] } } ] }

Just a note - using Safari on MacOS, going to the Source Code page, no matter where I click, even blank space, goes to the url: https://gury.atari8.info/listdet.php?id=15031&src=5&c=catId=156&catName=Games Actually, even from the Home page, it's like the whole page is covered by a region that only goes to one URL. If I scroll down, I can click the links that would be below where the first screenful of info is.

Tiny update, my v1.0 with the new firmware boots just fine. Tried on my 800XL ?

Success!! That firmware seems to have done the trick. Rebooted several times before and after adding the WiFi info, and after inserting my SD card! This was on the new device, I’m going to flash my v1.0 and see but I have hope! thanks!!

With awesome help from @mozzwald, I discovered what may be a possible cause… I plugged in a blank FujiNet, without an SD card, and it booted right up, to the WiFi selection screen. Yay. I then shut down, inserted my sd card, and…. Back to not booting up. Boo. I tried removing the sd card, but it retained the WiFi settings and still didn’t boot. I then did a reset (hold down B until the leds go off then hit C). Power down and back up booted up fine again. This time I selected my WiFi, entered the password and got to the Config screen. Power down and back on… no booting. after testing, I believe that it has to do with connecting to the WiFi that is causing the delay in booting. If I reset, I can power cycle over and over and it boots up. Once I add the WiFi (either selecting it or inserting the Sd card, no boot) I tested my old 1.3 version and it does the same.

FujiNet 1.0 - With USB Power - 4.748V Without USB Power - 4.748V FujiNet 1.3 - With USB Power - 4.812V Without USB Power - 4.812V As an aside, I'm seeing errors in the FujiNet Flasher app when trying to either show the debug output, or attempt to do an update: Nevermind that, replugging the USB adapter seems to have fixed it.

When I tried with a power supply, yes. I didn’t even know it had that value in the web interface. I will check both and let you know. I was playing with the SD card inserted and not on both. Without the sd card (I have two that have both been working just fine), I could get it to boot on power up, sometimes. (I did the reset as mentioned in the other thread (hold down B and push reset). That seemed to work-sometimes- but if I pull the FujiNet out and reinsert it, back to no booting. I’ll get you the voltages.

I wanted to pull this into it's own topic, from I know it's been a while, but has any progress been made to this problem? I'm still seeing the issue on my 130xe and my FujiNet's (v1.0 and v1.3). Again, turning on the computer doesn't boot the FujiNet - something seems to be delaying the FujiNet from starting up in time for the 130xe to recognize it and boot off the device. If I add power to the FujiNet, so it's all booted up, (either an external cable, or the USB to my computer), since the it's already booted, it starts up just fine. If I don't have anything plugged into it, and once the XE comes up, I then type "BYE" to get to the system test, then hit Reset, I can get the FujiNet to boot. I tried my 800XL, and it does the same thing.

I know it's been a while, but has any progress been made to this problem? I'm still seeing the issue on my 130xe and my FujiNet's (v1.0 and v1.3). Again, turning on the computer doesn't boot the FujiNet - something seems to be delaying the FujiNet from starting up in time for the 130xe to recognize it and boot off the device. If I add power to the FujiNet, so it's all booted up, (either an external cable, or the USB to my computer), since the it's already booted, it starts up just fine. If I don't have anything plugged into it, and once the XE comes up, I then type "BYE" to get to the system test, then hit Reset, I can get the FujiNet to boot. I tried my 800XL, and it does the same thing.

Very cool! Downloaded and tried on my MacBook Pro M1 Max. Seems to run fine, though I run in dark mode, so some of the screens are a little hard to read. Good job! This will be fun to play with.

I have a new MacBook Pro M1 Max 14" with Monterey 12.1, and the flasher worked just fine for me, for both a v1.0 FujiNet and v1.3(fixed).

I've not done any mods to it, and as far as I know none were done to it.