It was a foolish mistake that confused a return code indicating that there were no files on the disk with an error
Fixed now
GitHub has the latest code and binaries.
DSK tool
Re: DSK tool
Cool!, I'll try it again and report back ASAP.
Last edited by jltursan on Sun Mar 22, 2020 5:33 pm, edited 1 time in total.
Re: DSK tool
It works!...after some fixes...
Seems that with my Linux (yes, this time I'm using Linux) setup has some compatibility problems with the sources of dsktool and I've been forced to make some changes.
I'm using latest Linux Mint (Ubuntu Bionic based) with x64 GCC 7.5.0 and seems that the support of C++17 features is limited; so I've changed some things to turn it into a compilable tool.
Next, using it as part of a VSCode task I've created a handy toolchain to work with assembler files:
I can launch a TC01 or TCS256 emulation at will.
Now I need to find a way to autoexecute a .COM file when booting a disk and I'll be happy forever
Seems that with my Linux (yes, this time I'm using Linux) setup has some compatibility problems with the sources of dsktool and I've been forced to make some changes.
I'm using latest Linux Mint (Ubuntu Bionic based) with x64 GCC 7.5.0 and seems that the support of C++17 features is limited; so I've changed some things to turn it into a compilable tool.
Next, using it as part of a VSCode task I've created a handy toolchain to work with assembler files:
I can launch a TC01 or TCS256 emulation at will.
Now I need to find a way to autoexecute a .COM file when booting a disk and I'll be happy forever
Re: DSK tool
You need to edit the keyboard input buffer on disk so when the dos loads the keyboard buffer is pre-loaded with the name of the program you want to run. It's detailed in one of the books, either 'Albert Revealed' or 'The Source'.
Re: DSK tool
Thanks!, that's it, I've found a detailed description in "Einstein Compendium", AUTO-BOOTING chapter in page 59.
In the meanwhile, as it's only to finish the toolchain with an autoexecution, I've used a MAME feature and added some autoboot commands to autoexecute my compiled program:
The above parameters make MAME to wait 4 seconds and then, auto-type PROG+ENTER to run PROG.
Good enough!
Now, the hard job, learn how interrupts work and look for the best way to detect vertical sync...
In the meanwhile, as it's only to finish the toolchain with an autoexecution, I've used a MAME feature and added some autoboot commands to autoexecute my compiled program:
Code: Select all
-autoboot_delay 4 -autoboot_command "PROG\n"
Good enough!
Now, the hard job, learn how interrupts work and look for the best way to detect vertical sync...
Re: DSK tool
The einy doesn't pass on the vsync from the VDP as you probably know. You can read the interrupt bit from the VDP though, which helps.
Have a look here. It's not perfect but may well be a good start.
Have a look here. It's not perfect but may well be a good start.
Re: DSK tool
I mean. Why? Why didn't they do that? It's the _single_ most important interrupt in any gaming type application! The mind boggles
Re: DSK tool
...but seems that people at Tangerine made the same mistake with the Oric
Yep, my first approach was also to poll the interrupt bit of the VDP; but I was curious about the interrupts framework of the Einstein. Pretty different to the others I know, I've been learning from your sources (biggoil project) and found the CTC routines to setup an IM2 interrupt and I've tied this to the VDP 50Hz vblank. Of course, using MAME I can clearly see that the CTC interrupt drifts slowly from the vblank.
Now I want to check it with the real machine to see how accurate is MAME (I guess not too much). Anyway, these methods are good enough to play music & sounds and to increment a frame counter so I think it's solved for now.