Commander X16

voidstar wrote: ↑Tue Aug 08, 2023 5:03 pm Yep, I forgot that line at the top, forgot we're back in 1980 again

Ok, I put " *=$0400" at the top. Now it passes validation. Yeehaw!

Also beware when you generate code, if the file already exists it might not overwrite it - not sure if a way to force overwrite. But I missed that warning and was running old PRG by accident (I had to manually delete it first).

BUT.. then I tried SYS $0408 and I'm not sure if the program is running correctly (not seeing values written back to $B000 like I expected). Will try again later, gotta drive for a bit [ tried $2000 instead, same issue - maybe instead of treating it as a PRG to LOAD we gotta treat is a .BIN and load it via the monitor? ]

Also, your program starts at $0400, if you start it at $0408, you'll execute wackiness starting in the middle of the code. Specifically:
ora ($b0,x)
nop
jsr $fecc

Note that this neatly bypasses all your writes to $B000.

Ok, got it all sorted. After exiting ASMEDIT back to BASIC, there were some oddities (within r43) of doing a LOAD still going to $0801 (even though when I looked at the PRG hex itself, 01 08 wasn't the first two bytes). Not sure what was going on there, but it's why I thought I had to SYS past the first few bytes maybe. Anyway, after exit ASMEDIT, I had to reset the system and then do the load. And now it seems to work "end to end" with this simple example.

Bravo. The more tools we have for this machine, the better.

voidstar wrote: ↑Wed Aug 09, 2023 3:23 am

Sweet! "By default" LOAD thinks you want to load your stuff at $0801. When you add the extra parameters (,8,1) it knows you know your shit and won't try to "help you" by loading it at $0801 despite what's in the file. At least I think that's how it works.

Something I thought of yesterday, I'm not sure why this didn't occur to me before that... I have no actual hardware, so I have to always use the emulator and habitually add "-debug" to the command line to use the debugger, which is great. But when I switch to actual hardware, I won't have that anymore. I guess I'll just have to use the monitor, but I like the debugger a whole lot better.

There's no real good solution for this... the debugger is a "remote debugger" that's not even part of the simulated X16 in the emulator (For one thing, it would be magically sprouting a third VERA level.) So to get that, it would have to be on a separate computer anyway.

Trying new version and having trouble.

First, I RUN the loaded PRG.
- Create new file
- F3 to enter EDIT mode
- Enter the sample .SOR to generate random numbers (as described earlier). The forum isnt letting me attach .SOR files, so may have to type it in.
- use ESC and SHIFT+X to save the file, creates the .SOR file to disk
- x to exit, get back to menu, Generate Code
- this makes SAMPLE.PRG as attached below

I think the code generated is fine - it matches what I used in the earlier discussion. So issues are:
- I can't use CMDR-DOS LOAD command. Does that always try to load to $801? If so, that's fine
- instead I use BLOAD "SAMPLE.PRG",8,1,$2000 (because the code is .org'd at $2000)
- the code calls RNG, writes the results start at $1000, then goes to MON (so you can view the result)

But in the MON, I'm never seeing the result at $1000 as expected.

Thoughts? And if you're on Discord, can you share some other .SOR examples we can use on the SD-card? Simple stuff, just to show the workflow here.

I'm using R45.

LOAD first reads a 2 byte header from the file which denotes the address to be loaded.
If that two byte header is present and you use BLOAD than that two byte header is ignored.

I understand your program to be as follows:

*=$2000
20 cf fe jsr entrogy-get ;get 24 random bits
8d 00 10 sta $1000
8e 01 10 stx $1001
8c 02 10 sty $1002
20 cc fe jsr monitor

LOAD"SAMPLE.PRG",8

This command loads the program to $0801 ignoring the first two bytes (i.e. the location address: $2000) which is incorrect.

BLOAD"SAMPLE.PRG",8,1,$2000

This command loads the program to the correct address ($2000) but includes the two byte header as part of the program, which is incorrect.

The correct way to load the program is with

LOAD"SAMPLE.PRG",8,1

This command uses the first two bytes to determine the program location, but is not included in the loaded code.

With regard to more examples, there is a 'HELLO WORLD' example in the new version of the reference manual with a YOU TUBE video
link so you can follow the work flow. https://youtu.be/HTeLqSqDS84

Hope this helps

I'm trying to load ASMEDIT into the editor via:

sarasaworks$ ./x16/x16emu -prg ASMEDIT.PRG -run

But instead of running, it either loads to a discombobbled emulator screen or into the monitor with the following readout:

B*
PC: 9F0B
RA: 03  
RO: 00
AC: 01
XR: CC
YR: 00
SP: 01
Flags: ..***.**

The one time it loaded correctly, it crashed my Raspberry Pi. Please Help!!

Sarasaworks wrote: ↑Fri Aug 09, 2024 6:44 pm I'm trying to load ASMEDIT into the editor via:

sarasaworks$ ./x16/x16emu -prg ASMEDIT.PRG -run

But instead of running, it either loads to a discombobbled emulator screen or into the monitor with the following readout:

B*
PC: 9F0B
RA: 03  
RO: 00
AC: 01
XR: CC
YR: 00
SP: 01
Flags: ..***.**

The one time it loaded correctly, it crashed my Raspberry Pi. Please Help!!

Are you running the latest emulator release? We are currently on R47 (released in March this year).