Page 2 of 2

Re: DSK tool

Posted: Fri Mar 20, 2020 8:43 am
by sirmorris
It was a foolish mistake that confused a return code indicating that there were no files on the disk with an error :oops:

Fixed now :D

GitHub has the latest code and binaries.

Re: DSK tool

Posted: Sun Mar 22, 2020 1:30 pm
by jltursan
Cool!, I'll try it again and report back ASAP.

Re: DSK tool

Posted: Sun Mar 22, 2020 5:33 pm
by jltursan
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:

VSCode_Einstein.png
VSCode_Einstein.png (137.97 KiB) Viewed 11141 times

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 :D

Re: DSK tool

Posted: Sun Mar 22, 2020 10:30 pm
by sirmorris
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

Posted: Mon Mar 23, 2020 11:06 am
by jltursan
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:

Code: Select all

-autoboot_delay 4 -autoboot_command "PROG\n"
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...

Re: DSK tool

Posted: Wed Mar 25, 2020 10:50 pm
by sirmorris
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.

Re: DSK tool

Posted: Thu Mar 26, 2020 9:26 am
by sirmorris
I mean. Why? Why didn't they do that? It's the _single_ most important interrupt in any gaming type application! The mind boggles :roll:

Re: DSK tool

Posted: Thu Mar 26, 2020 3:28 pm
by jltursan
Interrupts.png
Interrupts.png (220.17 KiB) Viewed 11108 times
Obviously the Einstein was conceived as a bussiness machine... :mrgreen:
...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.

Re: DSK tool

Posted: Fri Mar 27, 2020 7:04 am
by sirmorris
jltursan wrote:
Thu Mar 26, 2020 3:28 pm
Obviously the Einstein was conceived as a bussiness machine... :mrgreen:
Yes, that's what I think.