desertfish

I went through (parts of) the same exploration when trying to figure out how to add floating point support to Prog8. Don't hesitate to ask if you have additional questions!

In the file assembler topic we had some peculiar findings regarding i/o speed as well . To me, it seems that there is something going on in the emulator that skews the results

You could also try to use the basic/kernal floating point routines such as FOUT $fe81 to print the floating point values

Here's a version of the assembler to play with. It doesn't support symbols yet so stick with basic assembly. It also only writes output directly to memory for now. The video shows it in action on a simple hello world program: cx16mf-2021-01-14_22.07.31.mp4 assem.prg

Do I understand correctly that this program provides its own code and storage format for dealing with floating points? Or does it use the same binary storage format as what the basic in rom does?

Would the simple answer not be: "just return from main()" with a final RTS? As long as you make sure the SP is valid before doing that final RTS, and you didn't overwrite the data that was already on the stack before your program starts, and the part of the zero page that basic and kernal use is not overwritten, and the screen and I/O configurations are reset to the defaults, you should return to the ready prompt cleanly With TSX and TXS instructions you can even store and restore the SP from anywhere in your program. Prog8's exit() routine uses this. Soft-resetting the system is also possible as @codewar65 mentioned, but this clears your program (easily recoverable via "OLD" though). I am not entirely sure if the setting of $01 is correct though for the changes that are coming in the banking register location, but this is what I use currently for a soft-reset routine: sei lda #14 sta $01 ; bank the kernal in (? new way?) stz $9f60 ; bank the kernal in (old way) jmp ($FFFC) ; reset vector

I've just made a BETA release of Prog8 6.0 available. It contains a huge pile of improvements and changes, among which: restructured part of the library modules, may break old code moved many built in functions that should just be subroutines, to the library module "sys" or "string", may break old code commanderX16 virtual registers cx16.r0 .. r15 available (for both cx16 and c64 compiler targets) added new library modules and routines such as gfx2 and new diskio stuff I've been using this version to create the multi-file-format imageviewer demo with color cycling, the highres bitmap graphics demo, and recently the W.I.P. file-based assembler. It's still a beta release so things might still change, but I wanted to shove it out the door because it works very well for me at this time and the list of changes and improvements is getting pretty huge so it would be a waste to not let others use it as well already.

Thanks a lot Stefan, to take the time to investigate and discover the unexpected factor of difference here! Running the I/O inside an IRQ handler sounds too much of a weird kludge and strikes me as not reflecting the true behavior of the physical machine, but rather an artifact of the emulator. I'll stick with just writing our I/o loops as we were doing now and not think much more of it for the time being.

Yeah I tried several things already but they didn't change anything (disabling interrupts, adding ",s,r" to the filename, using a different secondary device number). Very peculiar, I'd like to solve this issue but it seems it will require a lot more trial and error time than I anticipated so I think I'll put it on the back burner for now. For smaller files it's less noticable but we didn't want to do this project for small files

That's really odd. Is X16edit doing something before loading files? Changing vectors, disabling IRQ, or something else? Otherwise I may have to try to integrate your I/O routine in my program to see if that makes a difference...

There is: the READST kernal routine.

I need some help to find out where the difference in loading speed comes from..... My program doing just the bare minimum (load a byte with CHRIN, store it in $02, loop until eof) takes almost 8 seconds to finish. Reading the same file into x16edit takes around 4 seconds, and it is doing a lot more while loading ... I don't get it Can anyone take a look perhaps? Here is my program: .cpu "65c02" *=$0801 ; 10 sys 2061 .byte $0b, $08, $0a, $00, $9e, $32, $30, $36 .byte $31, $00, $00, $00 start phx ldx #<_filename ldy #>_filename lda #10 jsr $FFBD ; SETNAM jmp _go _filename .text "romdis.asm" _go lda #0 tax tay jsr $FFDB ; SETTIM 0,0,0 lda #1 ldx #8 ldy #0 jsr $FFBA ; SETLFS 1,8,0 jsr $FFC0 ; OPEN ldx #1 jsr $FFC6 ; CHKIN, use #1 as output channel ;lda #'.' ;jsr $FFD2 ; CHROUT ; load the file .... _loop jsr $ffb7 ;READST bne _eof jsr $FFCF ;CHRIN sta $02 ; store... jmp _loop _eof ; close stuff jsr $FFCC ;CLRCHN lda #1 jsr $FFC3 ;CLOSE ; print the time taken jsr $FFDE ; RDTIM -> A,X,Y tay txa jsr $fe03 ; GIVAYF jsr $fe81 ; FOUT sta 2 sty 3 ldy #0 _printlp lda (2),y beq _endstr jsr $FFD2 ; CHROUT iny bne _printlp _endstr plx rts And an sdcard image containing the "romdis.asm" text file is also attached including the 'loadtest.prg' program above loaddtest-img.zip

Thanks Stephan. It seems the effort that I've put into Prog8 is now starting to pay off... The assembler logic is indeed already independent from where the main loop gets the lines from (it can also run in interactive mode like by line that you enter manually). Are you suggesting to add a third source, a source file completely read in memory? I avoided that for now because I can't deal with banked memory yet and the source files will not all fit into main memory I am not sure why my file I/O seems to be a lot slower than your x16 edit .... a dummy loop to just read the file (and not process anything), basically calling CHRIN() in a loop and storing the bytes in memory, takes 6 seconds for a 16 kb file .... I may need some help to debug that to see what could be the cause. I'm thinking: could it be an emulator thing? that my emulator is just reading things a lot slower than yours? I'll try reading the large file in x16 edit tonight myself to compare the load speed. Is x16 edit reading the full fine into memory when you open it?

Worked a bit more on my attempt at a file-based assembler. Basic assembler functionality more or less done, it can more or less assemble a raw disassembly now. No labels, symbols or other things yet I also ran it on a 8200 lines long disassembly dump of the Commander X16 ROM region of $c000-$ffff (16 KB) and it took about 12 seconds to assemble that (into memory). Half of that time is spent just loading the source code from disk... and we're not yet writing the result to a new file so that would probably add about six seconds more... adding labels and symbols functionality will require re-reading the source file at least one extra pass so that adds six seconds once again. A disk-to-disk assembler will be pretty slow compared to an in-memory assembler... For now it's still an example that's part of the Prog8 compiler repository so the source is here https://github.com/irmen/prog8/blob/master/examples/cx16/assembler/assem.p8

Hang in there! Welcome and hope you find some retro distractions here!

Goed bezig!

Also it has to interface with a lcd panel. No regular monitor cable

"german" ... "buttons and lights" ..... aha DAS BLINKENLIGHTS mit den Gefingerpoken ! Sorry couldn't resist Welcome

hehe yeah man the dog is always a nice cameo in Perifractic's video's I love them too

If I want my programs now to be compatible with the older configuration (and V38 emulator) and also work with the new $00/$01 bank registers, will it be okay to simply write the same value to $9F60 and also to $00 (for rom bank) and $9F61 also to $01 (for ram bank) or are the old bank registers repurposed and it it no longer safe to write to them like this? (also do i have the order of $00 and $01 correct?)

@TomXP411 what helped a lot for me is to understand that when you load "$" from the disk drive, it is actually making it as a basic program listing for you. So the format you have to parse is how a normal basic program works in memory! Line numbers are the block sizes. That's why the default way of doing LOAD"$",8 : LIST works as it does (but overwrites your current basic program) By the way the basic program you linked above gets confused about the line numbers/ block counts it seems and starts printing garbage after a few files, unfortunately. I tried it in the emulator with a sdcard image attached with about 30 files on it. Here's my take on doing it (in prog8) https://github.com/irmen/prog8/blob/master/compiler/res/prog8lib/diskio.p8#L8

The fun thing is I studied your source code for XEdit to get me going initially with the disk i/o functions !

Odd, secondary address 0 should and does work for me. The code that I use essentially does OPEN 13,8,0,"$" - read byte from channel 13 and print it to the screen, until break/error/EOF - CLOSE #13. (the printing is a bit more involved than that because it has to decode the block numbers) Are you sure you SETNAM/ SETLFS correctly?

Combine the tool that I mentioned a few comments up on this page, and the info from this thread: