Novamaker release and testing Hello, I coded a simple cross-tool that turns PRG files into Novaload encoded TAPs. It's called Novamaker (Novaload maker). Please post a follow up if you have any advice for improving it or if you found a bug. In particular, I appreciate any suggestion regarding pulse and pause values. The PRG must be RUNnable.
To use it, open a terminal and type (use quote marks where spaces are involved):
novamaker prg_file tap_file found_str
Here's the archive (binaries for Windows and Linux are provided): https://drive.google.com/file/d/1lEjocMbbEcSSf8CjRkJFRrGIYoDn0nz1/view
Re: Novamaker release and testing Whoops, I forgot to bump the version number. Sorry for the multiple posts. Here it is: https://drive.google.com/open?id=1noJ6DB1Mvi5xfTsHLsM3OegiOKwAjqsV
Re: Novamaker release and testing Oh, come on, this stuff really works! Congrats! Finally, I can say farewell to all those horrible Novaload saving native utilities which, let's say the truth my friend, have never NEVER worked :D Ain't not able to use the "+" sign in a FOUND filename, though...
Re: Novamaker release and testing Well done Basman, this is pretty neat!
My suggestion would be to allow default parameters for everything besides the PRG filename. If one was to run this with novamaker.exe BLAH.prg, assume the TAP filename to be BLAH.tap and the found string to be BLAH.
<prg> filename of the program to encode -t <tap> tap filename (defaults to the prg's name with .tap extension) -f <found> found string (defaults to the prg's name, minus the extension) -j <jump_addr> jump address, either decimal or hex (0x... (max 4 digits)) -v verbose mode
Re: Novamaker release and testing V 1.5 with (hopefully) proper handling of slashes and dots in pathnames. This was needed to correctly build TAP filenames and FOUND strings from PRG filenames. You should now be able to drag & drop Plus/4 programs onto Novamaker with the expected results.
Please let me know if I'm cluttering the Forum too much with my updates and I'll try to arrange something both for hosting this utility and for users to contact me with bug reports and general feedback.
Re: Novamaker release and testing Wow, I haven't tried it yet, but the idea is really neat and the pace of updates is absolutely amazing! Well done and keep it up!
Re: Novamaker release and testing Very nice video, I love the enthusiasm! Btw, if you use Novamaker very often (and if I haven't done something wrong), note that you should be able to drag & drop your PRGs (one at a time) on top of the executable for a quicker conversion. Better yet, you could add Novamaker to the "Open with..." context submenu for .PRG files. Both methods should give you a TAP file in the same folder and with the same name as your PRG file, with a 'TAP' extension and a FOUND string reflecting the filename itself. Should you prefer a different FOUND string, just rename your PRG file as desired and use one of the above methods.
Re: Novamaker release and testing Thanks Basman for the great work and thanks Luca for posting a link to my video totally unsolicited! I really appreciate it and I'm glad you liked it.
This site is a fantastic resource for C16 and Plus/4 fans and I keep singing it's praises on my channel
I still have so much to explore, I am especially fascinated with the popularity of the system in Hungary, Germany etc. Great stuff!
Re: Novamaker release and testing Basman I have a request for the Novamaker: in order to shield programs that occupy the memory under $0800, you could add in the Novamaker files a slice of code that stores somewhere the location $07FC while loading, and uses the stored value to restore the original value there when the tape stops by writing in $07FC. The last jump to the program will be: LDA value STA $07FC JMP run
Re: Novamaker release and testing Thank you! At this point, let me go further and ask for some other optins, like charset/bitmap choice (I had to add the code by myself, you'll see in some hours ), or something else I can't figure out now .
Re: Novamaker release and testing The more context you give me, the better. Is the $7fc problem always related to loading screens? Could you provide examples of PRGs that are affected, original Novaload tapes that deal with that (if they exist) and tapes with loading screens?
Re: Novamaker release and testing Just my recent experience: $07fc changes once the loading has been completed, and if you're trying to load something even under that location, it will result corrupted due the kernel loader to write a $88 in $07fc, which means: tape stopped.
Re: Novamaker release and testing Basman: tested, the loader naturally continues to write $88 in $07fc once the loading is complete, which seems to be inevitable. The solution would have been to save in $013f (the first save unused value before the Novaload code) the original value in $07fc, finish the loading accepting the $07fc change due the kernel, then copy back the stored value before jumping to the program start
Re: Novamaker release and testing If you look at $01A2 during loading, you should see the code that restores the "rescued byte" and jumps into the loaded program. I should probably put a SEI on top, to prevent the kernel from overwriting it anyway, but this could have unwanted effects. I don't know if the loader overwrites it too, but that shouldn't make a difference with the new restore code. For now, please just check if the code is there and it's correct. If possible, please provide some PRGs for testing. I'm starting to doubt that what we're trying to achieve is possible.
Re: Novamaker release and testing I've tested it again, exactly in the same way and wih the same prg...and it worked! :O I really dunno what has happened the first time...weird... Anyway 1.6beta works to me Thank you!
Re: Novamaker release and testing On second thought, it may still be incorrect. What if, in the previous test, the problem had been a system interrupt that occurred just before the final JMP? I wonder if we can devise some code to wait for an interrupt and then jump, and make it small enough to fit. Maybe wait for a specific rasterline?
Re: Novamaker release and testing Yes, tested several times the same .tap, sometimes it works, sometimes it doesn't. The sequence seems to be regular: first, the machine writes $88 into $07fc, after that, in a couple of sacnlines, your code writes back the wanted value. What happens after the first step, that finishes into a CLI?
Re: Novamaker release and testing I didn't code the loader, I only did the patch that replaces the Basic RUN with the JMP and the "byte rescue" thing, so I don't know what it does. Some thoughts: - If the loaded program doesn't start with a SEI, the byte can be messed up by the Kernal even after it has started. If it expects a specific byte in that location, it also expects interrupts to be already disabled, doesn't it? - This looks like a corner case: a program that relies on a location that the Kernal overwrites several tens of times per second. We should probably let the program initialize it under safe conditions and leave Novamaker agnostic and simple as it is. I think modifying the program is a cleaner solution.
Re: Novamaker release and testing Actually I tested am exomized .prg, it starts with LDY#$XX SEI, so I tried to invert the command in order to have SEI as first operation, but it keeps crashing... In any case, the $07fc facility is a good addon ;)
Re: Novamaker release and testing Mmm...dunno, I wonder it won't work... :-\ Here's what I think it truly happens: the code which puts $88 as tape stopper into $7fc, also switches ROM sith STA $FF3E, maybe something can probably happen again after we force the copied value into...?
Re: Novamaker release and testing We're probably running in circles here. I guess the load range of your exomized program doesn't include that location and Novamaker didn't force you to specify a jump address, so my modification did exactly nothing for you! The corruption most probably happens after the decompression. You should instruct Exomizer to exit with interrupts and ROMs disabled. Please check the load range of the Exomized program.
Re: Novamaker release and testing Err...nope: the program meets the wrong value *before* starting to decrunch, and what results after got compromised by that wrong value. Anyway: yes you're right, we're running in circles here I think the best to do here is keeping the $07fc feature, which is generally a good thing to have, and let the user dab against further troubles
Just for completing the picture: I faced this problem when I had to use Novaload for the tape version of Daley Thompson's Star Events +2FG!: first Novaload loads the bitmap picture, then start to load the main part, which occupies the memory $06ab-$3ff. I solved the problem adding a forced restore of the $07fc value there
Re: Novamaker release and testing Version 1.8. Changes:
Bugfix: stored .tap data size was 20 bytes too big new feature: use your own header/loader prg files new feature: encode multiple files removed feature: byte rescue (now redundant)
Novaload maker v 1.8
Usage: novamaker <prg>... [options]
<prg>... filename of the program(s) to encode -t <tap> tap filename (defaults to 1st prg's name with .tap extension) -f <found> found string (defaults to 1st prg's name, minus the extension) (use "" or spaces to keep the string that's already in the hdr) -j <jump_addr> jump address, either decimal or hex (0x... (max 4 digits)) -h <header> custom header -l <loader> custom loader -v verbose mode
Please, test and give feedback, thank you!
Get it here (win32, linux32, linux64): https://drive.google.com/file/d/14Xi35MhIqk6aJkdIJskA_qxXRBL4xvnk/view?usp=sharing
Re: Novamaker release and testing I'm testing it trying to replicate what I obtained for Daley Thompson's Star Events +2FG!, just in order to see if the byte rescue flaw has really gone, but it doesn't load the second part. Which filename is assigned to the other .prgs after the initial one, just to give $FFBD the right values? I've just tried with #LDA #$00, or with the same filename assigned with the -f option, but still doesn't work.
EDIT: ok, no $FFBD to assign any further filename, and it worked! And yes: it still suffers of the $07FC forced value of $88. is the voice "custom loader" also intended as " a slice of code yuo can add to the Novaload itself"? Hence, if I got the idea behind, it's up to the coder to: save $07FC after the tape loading, set the graphic modes, set the colors. Anyway,said that, the tool works, and it's cooler than ever, thank you!
Re: Novamaker release and testing Thanks for your appreciation, Luca! By custom header/loader, I mean the CBM parts ahead of the Novaload block(s) (Novamaker has a CBM encoder besides the Novaload one). The principle is giving the user full control on what they do (restoring corrupt data, centering the filename on the Novaload text screen, etc.). I used your Daley Thompson crack for my tests; once you use the very same data to rebuild the tap file, it must work no matter what, doesn't it? Take a look at this archive. It contains all the files from your crack and a batch file to rebuild the tape.
Anyway there can be special cases where it won't work. Currently, you can't customize Novaload filenames; it always uses the string "NOVA". Your crack uses it on both files, so no problem there. I don't know anything about that $FFBD / filename stuff (I made this program without looking too much at the actual 6502 code). Could you explain?
Re: Novamaker release and testing Thank you for the quick answer, and for your effort on this cool tool. At the moment, I haven't tested it yet, but just to advice that nova2.prg obviusly included my forced fix in the very initial JMP at $06A6, so if you run that version of course it works
Wandering aroud my thoughts, whereas the tool itself does includes just .exe files, the example pack also have header.prg and loader.prg, which actually should be the Novaload splitted into two, right? Having these into the official release, one can physically change'em to change both the beginning (graphics and stuff) and the ending (fixing) of the Novaload, right? If yes, they should be officially included into the whole tool
$FFBD is the Kernal subroutine to assign a filename e.g. to be loaded, essential to normalli load a file. My crack actually assign an eventual filename, if I use your tool once I called the Kernal routine to search for what I intended to be a file with a name, it fails; if I delete that JSR $FFBD it works. This occurs probably because my cracked game use to unchained Novaload files, whereas your tool saves the subsequent Nova file directly as data to be loaded in halfwaves, no FOUND required.
<prg>... Filename of the program(s) to encode [-n <novaname>]... Novaload block name(s) [-t <tap>] TAP filename (defaults to 1st prg's name with .tap extension) [-f <found>] Found string (defaults to 1st prg's name, minus the extension; use "" or spaces to keep the string that's already in the header) [-j <jump_addr>] Jump address, either decimal or hex (0x... (max 4 digits)) [-h <header>] Custom header [-l <loader>] Custom loader [-u] Unbootable (no CBM header/loader) [-v] Verbose mode
New: custom Novaload names New: can compile unbootable tapes New: some examples included
Get it here: https://drive.google.com/file/d/1Q9v6f0l3W1uzCNXRqpQSdgZ40aOwHmUy/view?usp=sharing
Re: Novamaker release and testing Love to see your tool improving more and more The fact that you again use my cracked game which fixes the $07FC value by itself means that it has been left to the user to be solved, right? Even Spy Vs Spy has one file loading at $0600, but that slice of memory is practically a copy of the standard memory on a C16/Plus4, it loads a value of $04, then it changes to $88 as ever, but it doesn't affect any of the game, so it wi ll work anyway. You should try my game's crack, but with the file NOVA 03 saved and run to $06AD, cutting off the forced fix I put into it ;)
> the example pack also have header.prg and loader.prg, which actually should be the Novaload splitted into two, right?
Exactly. As you probably know, most tape loaders are made like that. A standard CBM header is 192 bytes long, though it only contains a 16 characters filename, a file type (1 byte) and a load range (4 bytes). So a 3rd party tape loader is often partly contained in the CBM header, while the remaining part is in the actual PRG that follows. On the C64, I've come across at least a couple of loaders that are entirely contained in the header, while the PRG part just consists of 2 bytes that overwrite a system vector when loaded, causing the execution of the code that's in the header. I chose the terms "header" and "loader" for my tool, but you're right, it's the loader split in 2.
> The fact that you again use my cracked game which fixes the $07FC value by itself means that it has been left to the user to be solved, right?
Yes, I removed the $07FC restoration feature because it hindered the readability of the code and it is impractical (if at all possible) to automatically patch unknown loaders or prg's that way.
> You should try my game's crack, but with the file NOVA 03 saved and run to $06AD, cutting off the forced fix I put into it
Re: Novamaker release and testing > Yes, I removed the $07FC restoration feature because it hindered the readability of the code and it is impractical (if at all possible) to automatically patch unknown loaders or prg's that way.
Good to know. I wondered about storing the value somewhere when the loader would pointto that address, then restore it the loading has finished just before the final JMP. But I said, mine is simply wandering among thoughts
>> You should try my game's crack, but with the file NOVA 03 saved and run to $06AD, cutting off the forced fix I put into it > I will, you made me curious!
Try it! It will run, but the changed value in $07FC will break the Day 1 depacking, that's what you have to test ;)
> I chose the terms "header" and "loader" for my tool, but you're right, it's the loader split in 2.
Oh, hence: if I don't use -h and -l options, novamaker.exe uses both covering the memory inbetween too; if I wanna add something mine to the code, I can edit both of them, then use the former the latter or both in the new shape I've given to them, adding e.g. new colors, setting a different graphic format and so on. The two files are respectively the samein the /daley_thompson_fire folder, called 00 header.prg and 01 prg.prg. My suggestion is to put them in a folder apart, maybe with their .asm sources too ready to be modified and compiled, in order to clearly offer them to any user for further handling.
The unbootable option should produce pure halfwaved data with no FOUND, initial header and so on, just halfwaved compressed data. You can use it for, e.g., multiload games.
Sure, you store the value somewhere then you restore it. You analyze the loader, see what it does, what memory it uses and doesn't use, then you patch it accordingly. I don't know how to teach my program how to do this with unknown loaders so it would only be relevant with the built in one. Or I should include more built-in loaders, but that would be too messy for my tastes.
I think the memory between header and loader remains untouched, as they are 2 different entities each with its own load range.
I've thought about providing disassembled loaders, but I'll let the user choose his own route as there are different (dis)assemblers with their syntax, or he may want to do his patching in the emulator, etc.
Lastly, you may be surprised to learn that my tool doesn't produce any halfwaves. I specifically chose Novaload because it doesn't need them. Hence, just wholewaves all along (TAP v. 1).
Novamaker release and testing
Finally, I can say farewell to all those horrible Novaload saving native utilities which, let's say the truth my friend, have never NEVER worked :D
), or something else I can't figure out now 
