| |
DubDee
Registered: Sep 2020
Posts: 6 |
Can not open Turbo Macro Pro
Well we still got problem to open this program.
https://style64.org/release/turbo-macro-pro-sep06-style
I try to LOAD"$",8,1
But I got just shredded letters all over the screen on both D64-files.
How do you open up this program on Vice or C64?
Is it working flawless for you?
Thanks
Cheers |
|
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
when you load a directory you have to do ,8 as it makes a fake BASIC program. |
| |
DubDee
Registered: Sep 2020
Posts: 6 |
Quote: when you load a directory you have to do ,8 as it makes a fake BASIC program.
Oh yes and then List and run from there.. Thank u! |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
I do wonder what the design decision was for the directory listing to use the screen address as a load address. |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
legacy from the PET drives? As the firmware system is similar isn't it?
0400 is the start of BASIC on a P.E.T |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
exactly that, the PET always loads absolute, so the directory listing starts at $0401 |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
You can't connect a 1541 to a PET, however, can you? =)
(It has a distinct "DIRECTORY" command next to LOAD, does that also stick to whatever is in the load address?)
But then BASIC programs start at a few different locations across computers compatible with the drive ($0801, $1001, $1c01), so picking any specific absolute load address would only work on one of them.
Loading to BASIC start goes over the entire program and re-links the BASIC lines by fixing up the linked-chain pointers, so yeah, i guess they just decided to stick to the original directory load address. |
| |
Peiselulli
Registered: Oct 2006
Posts: 81 |
Even worse : on the VIC 20 the start address of basic depends on adding/removing additional memory cards. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quoting KrillYou can't connect a 1541 to a PET, however, can you? =)
No, but close: https://www.c64-wiki.com/wiki/SFD-1001
I think that has most of the code base the same.
Quoting Krill(It has a distinct "DIRECTORY" command next to LOAD, does that also stick to whatever is in the load address?)
There's a "CATALOG" command in BASIC 4.0, though there are PETs with 2.0 and 1.0 BASICs as well which I presume doesn't have that. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:I think that has most of the code base the same.
even the 1541 is basically still a PET drive when it comes to the DOS :) |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: Quote:I think that has most of the code base the same.
even the 1541 is basically still a PET drive when it comes to the DOS :)
Yes, but it was quite a hack when they reduced the multiple CPU implementation to one CPU, which they did for the 1540. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting tlrYes, but it was quite a hack when they reduced the multiple CPU implementation to one CPU, which they did for the 1540. Still boggles the mind that the disk drives of the time ran with twice the raw computing power of the actual computer. =D |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
the HD (dont recall the product code, the tank sized 7MB one) even has 3 boards in it - each with its own CPU :) |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quoting KrillStill boggles the mind that the disk drives of the time ran with twice the raw computing power of the actual computer. =D
Yes, but I guess it makes sense given that the rest of the drive was very expensive. It surely reduced the development time splitting the problem in two (teams perhaps?).
I think it's possible to execute code on both CPUs of an older drive. IIRC they share a piece of the memory, e.g the block buffers, and you have a fast parallel interface so maybe realtime vector calc on a cluster of 4040's? :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
the second board/CPU is completely transparent, you cant run code on that |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: the second board/CPU is completely transparent, you cant run code on that
Are you sure? There are job codes for jump already in that implementation so it should execute code there. I seem to remember the actual formatting code is softloaded and executed, but I might be wrong.
EDIT:
******************************* Transfer format code to buffers 0,1 & 2
start controller formatting
E416 A0 00 LDY #$00
E418 B9 00 D0 LDA $D000,Y ;read format codes from ROM
E41B 99 00 11 STA $1100,Y ;transfer to RAM
E41E B9 00 D1 LDA $D100,Y ;read format codes from ROM
E421 99 00 12 STA $1200,Y ;transfer to RAM
E424 B9 00 D2 LDA $D200,Y ;read format codes from ROM
E427 99 00 13 STA $1300,Y ;transfer to RAM
E42A C8 INY ;all codes transferred ?
E42B D0 EB BNE $E418 ;no,
E42D A9 00 LDA #$00
E42F 20 92 EC JSR $EC92 ;transfer HEADER image to buffer
E432 A5 12 LDA $12 ;read current drive number
E434 09 E0 ORA #$E0
E436 8D 03 10 STA $1003 ;activate EXECUTE code in buffer (FORMAT)
E439 AD 03 10 LDA $1003 ;formatting of diskette finished ?
E43C 30 FB BMI $E439 ;no,
E43E C9 01 CMP #$01 ;disk formatted ok ?
E440 F0 07 BEQ $E449 ;yes,
E442 A9 03 LDA #$03
E444 A2 00 LDX #$00
E446 4C 1C D9 JMP $D91C ;jump to process encountered error type
E449 60 RTS
(from https://www.pagetable.com/docs/anatomy-4040.html#c9)
... so yes arbitrary code may be executed on the FDC 6504. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
that'd be news to me - the general consensus seems to be it cant be done. of course that can be wrong :) |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: that'd be news to me - the general consensus seems to be it cant be done. of course that can be wrong :)
I can only note that it seems to be part of how the DOS is working itself (i.e the formatter). Assuming M-W and M-E is possible on the IEEE controller 6502, it must be possible to run code on the FDC 6504.
I the consensus disagrees, the consensus cannot run code on it, but others could possibly do. :)
I guess this could even be tested to some extent in vice.
EDIT: I was thinking where I might have read the formatting note first, and it's in Inside Commodore DOS, p425. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
so test it :) (you can use a .tap file if you want to run the test) |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: so test it :) (you can use a .tap file if you want to run the test)
I might, but I can't seem to find how the switch to the 6504 context in the monitor. There seems only to be dev 8:
Anyway, there are several examples running code on the 6504 in that book on the pagetable link. Those all run it by writing in to the buffer at $1100 and m-w:ing the job code directly, no m-e. m-e seems to be in the ROM though so I'm positive it works, and was known since forever. Wasn't there disk copy protection on the PET?
This could be different for other PET drives of course, but I doubt it. Makes sense to be able to run code, if only for production test. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
VICE does "highlevel" emulate the FDC board i think, only the DOS cpu is TDE |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: VICE does "highlevel" emulate the FDC board i think, only the DOS cpu is TDE
booo...
Anyway have a look at src/drive/ieee/fdc.c. There's magic code to check if the formatter code has been loaded to RAM upon finding an $E0 (execute) job. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
I dont think my interest in this goes that far =D |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
From https://www.pagetable.com/docs/anatomy-4040.html#c9 as well:
$FD20 JOB ROUTINE: execute (mode E:110)
[...]
****************************** START: Test for a valid job
.Y = job queue number
.ACC = job
FC54 A0 0E LDY #$0E ;set for #$0E jobs scan (dec. 14)
FC56 58 CLI ;clear interrupt
FC57 B9 03 04 LDA $0403,Y ;does this queue have a job to do ?
FC5A 10 31 BPL $FC8D ;no,
FC5C C9 D0 CMP #$D0 ;is the job equal to #$D0 (execute ml user
code from data buffer)
FC5E D0 05 BNE $FC65 ;no,
FC60 84 1F STY $1F ;store which job queue is being processed
FC62 4C 20 FD JMP $FD20 ;jump to EXECUTE routine
[...]
FD17 A5 1E LDA $1E ;get current job being done
FD19 C9 60 CMP #$60 ;is job type #$60 (EXECUTE ML CODE WITH MOTOR
ON) ?
FD1B F0 03 BEQ $FD20 ;yes,
FD1D 4C 82 FE JMP $FE82 ;no,
****************************** JOB ROUTINE: mode=110 (E)=execute
(6)=start motor then
jump
FD20 A5 1F LDA $1F ;get current job number
FD22 18 CLC
FD23 69 05 ADC #$05 ;add in buffer index
FD25 85 17 STA $17 ;set HI pointer to USER assigned ML CODE area
FD27 6C 16 00 JMP ($0016) ;jump to user assigned buffer code
[...]
110: execute (E) (6): start motor then
jump
bit 0 drive: 0=#B, 1=#A
FDAA 48 PHA ;preserve job
FDAB 29 70 AND #$70 ;clear bits: 6, 5, 4
FDAD 85 1E STA $1E ;save calculated command code
So seems quite easily possible (and intended by the designers) to run user code on the disk controller 6504. And if weren't so easy, pretty sure some exploit could be found in that old code. =) |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
I note that the 6504 does not have an SO pin, so no BVC *. feels weird... :) |
| |
Count Zero
Registered: Jan 2003
Posts: 1932 |
Great to see a thread like this derail into such a nice discussion which could easily have its own thread *hint* |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting tlrI note that the 6504 does not have an SO pin, so no BVC *. feels weird... :) Maybe, butFDCB 24 4D BIT $4D ;new interrupt ?
FDCD 10 FC BPL $FDCB ;no,
FDCF A5 41 LDA $41 ;read PORT A: data input
FDD1 91 16 STA ($16),Y ;store into assigned buffer
FDD3 45 08 EOR $08 ;calculate new checksum
FDD5 85 08 STA $08 ;store new checksum result
FDD7 C8 INY ;all bytes read ?
FDD8 D0 F1 BNE $FDCB ;no, getting readily decoded bytes right from the hardware, with IO registers in zeropage, too, feels like quite the luxury. =) |
