Re: Auto Boot - and the & command.

Hello Julian,

* On Sun, Apr 07, 2013 at 09:24:15AM +1000 Julian Perry wrote:

> No - I have never seen a 901229-04 ROM . I came to the conclusion that
> it must have been an internal revision, never released.

I came to the same conclusion. Anywhy, I still hope someone will come up
with a -04 ROM. ;)


> Yes. I do recall seeing it frequently. If you asked me for the
> sequence to reproduce it, I honestly couldn't tell you. (it WAS 28
> years ago!)
> 
> The only thing I DO remember was that it started happening when I bought
> a printer (Star Micronics Gemini 10X) and serial adapter. Presumably
> the loading of the IEC buss by that device fooled the drive into
> running the code.

It could be either the load, or perhaps a different behaviour of such a
serial adapter (or even of a printer) on the bus.

I rechecked it: AUTOBOOT is not executed if CLOCK is not asserted or
DATA is not asserted on boot. That is, if either one of CLOCK and DATA
is at 5V, no autoboot will take place.

Note that the C64 initialises CLOCK and DATA to 0V on RESET
($FDCB-$FDD4). However, at $FDF6, it jumps to $FF6E, and there, the last
call is $FF7D which JMPs to $EE8E, clearing (=setting to 5V) CLOCK.

Thus, we have a race here between C64 and floppy. However, as this
initialisation is done on the C64 before testing the memory, while the
floppy tests it after testing the memory, in practise, the autoboot
could should never take effect in the combination C64 + 1541.

For the VIC20, this is different. While after initialisation, DATA is
set (0V), while CLOCK is unset (5V), the VIC20 performs this
initialisation AFTER testing the memory. Thus, we have a race here
between the floppy drive and the computer.

Fine, again, learned something new: Now I know why Commodore changed the
order of the initialisations in the RESET routine between C64 and VIC20:

; -----------------------------------------------------------------------
; This is the RESET routine that is called when a hardware RESET occurs.
; After determining if an expansion cartridge is available - in this case,
; this routine aborts and calls the RESET routine of the cartridge -
; it has to set up the I/O areas and all memory. Afterwards, it calls
; the BASIC through the BASIC cold start vector
;
RESET:
	ldx	#<$01FF
	sei			; no interrupts are allowed (we have not set it up yet)
	txs			; SP = $FF, so we have maximum stack space
	cld			; make sure we are in binary mode, not in decimal mode
	jsr	CheckCartridge	; check for an expansion cartridge
	bne	@NoCartridge	; no cartridge -> jump
	jmp	(CART_RESET)	; we have a cartridge, exit and call the RESET routine of the cart

; in case we have no cartridge, proceed with initialisation

@NoCartridge:
.if CompileComputer >= C64_GENERAL
	stx	VIC + VICII_O_ControlReg2	; switch to 38 cols mode
				; this seems to be cosmetic only. If the C64 already has a visible
				; screen, one can clearly see that the RESET makes the left and
				; right border smaller on a RESET and/or JSR $FCE2 (SYS 64738)
	jsr	iIOINIT		; initialise the I/O area
.endif

	jsr	iRAMTAS		; clear memory and determine RAM areas
	jsr	iRESTOR		; restore the KERNEL jump vectors
.if CompileComputer < C64_GENERAL
	jsr	iIOINIT		; initialise the I/O area
.endif

	; Initialise the video
.if CompileComputer >= C64_02
	jsr	iCINT_WITH_PAL_NTSC	; initialise the video. Also make sure to determine PAL or NTSC, and adjust the timings accordingly
.else
	jsr	iCINT		; initialise the video.
.endif
	cli
	jmp	(bRESTART)	; call BASIC
; -----------------------------------------------------------------------

It can be clearly seen the iIOINIT is called as (almost) last action on
the VIC20, while it is called as (almost) first action on the C64.

Perhaps, the switch of the screen to 38 cols mode on the C64 was a
debugging aid to find out if this change helps?

> I don't have that drive anymore - I literally wore it out, and it
> couldn't hold an alignment anymore. Stripped it for parts. (the
> transformer ended up as a modem power supply for our BBS!!!!)`

Well, testing this should not be a problem. There are many ways to use
another ROM in a drive. ;)

Anyone here with a VIC20 and a 1540 or an early 1541 who wants to do
some tests to confirm my findings, or to proove them wrong? ;)

Regards,
Spiro.

-- 
Spiro R. Trikaliotis
http://www.trikaliotis.net/

       Message was sent through the cbm-hackers mailing list