FloppyBuilder evolution

Anything related to the tools Tap2Wav, Tap2CD, Tap2Dsk, Sedoric Disc Manager, Tape Header Creator, WriteDsk, and generaly speaking tools related to the management of Oric data files and devices.
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: FloppyBuilder evolution

Post by Dbug »

Chema wrote:I am pretty sure both worked (although the one with the digitized sound sounded horrible). This is the first time I find this thing occurring, Dbug.
Since the Floppy Builder boot/loader is based on these, it mean I broke something accidentally, so I guess we need to find out when that happened.

The first Floppy Builder demo was Pushing The Envelope, is that one working fine?
Then it was Zero Fx
Then it was Oric Tech

If all these work, then it probably means I broke something later, like when trying to integrate the various fixes I got from numerous people.
User avatar
Chema
Game master
Posts: 3013
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: FloppyBuilder evolution

Post by Chema »

I tried, with two different disks, the three demos. I could only load OricTech once. And I tried +10 resets with each of them. The same symptoms... black screen, FDD stops and nothing happens.

When the demo boots, all the subsequent reads work OK.

I took one of those disks, dumped 1337 and it worked perfectly.

I tried Barbitoric and it worked OK (Silicebit sent it to me on a disk, so it worked for him too!).

It has to be some timing or error handling issue. Something that is done differently in the read_sector routines, which work OK (it seems).

EDIT:

Just managed to load Pushing the Envelope. Once it boots, it works and loads all the images and music. One thing, though. There are several pauses in the music and effects when data is loaded. The first one takes about 2 seconds. The rest are much smaller, but stop the music and scroller noticeably.
User avatar
Chema
Game master
Posts: 3013
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: FloppyBuilder evolution

Post by Chema »

As your ill probably fix this issue in a new version, I think it's time for me to upgrade. But there's something that worries me:
- Modify the detection of compressed/uncompressed files. DONE
Right now the loader checks if the compressed size of a file is equal to the uncompressed size and uses that to decide which loading code to use.
I suggest removing one of the two size information, and store the "compressed" flag as the high bit of the Sector number, that will not make the code any more complex, but that's two bytes less per entry of the directory.
I guess you need the compressed size to load the data, but I need the uncompressed size to search for a memory chunk to place the uncompressed data. If you remove this entry I am not sure how to deal with that.
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: FloppyBuilder evolution

Post by Dbug »

The uncompressed size is still available, just not saved by default.

You can use it with AddDefine defineName {FileSize}
Available values are:
{FileIndex}
{FileSize}
{FileTrack}
{FileSector}
{FileSize}
{FileSizeCompressed}
User avatar
Chema
Game master
Posts: 3013
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: FloppyBuilder evolution

Post by Chema »

Ah, great! Glad to know :)

And about the loading issue... any clue?
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: FloppyBuilder evolution

Post by Dbug »

Chema wrote:And about the loading issue... any clue?
Not really.

The thing is, I did not write the original FDC code, and Jede's code was also some trial and attempts.

I probably need to see what the differences between Barbitoric and Pushing The Envelope are, it's most probably some nops (too many or too few), but it's hard to diagnose on the real hardware.
Godzil
Squad Leader
Posts: 774
Joined: Sat May 21, 2011 7:21 pm
Location: Between UK and France
Contact:

Re: FloppyBuilder evolution

Post by Godzil »

Chema: if your code can detect some errors (maybe by read the FDC status register) you should change the bar color from magenta to red for example so you may have some slight info on the disk status.

One thing that should be rulled out, the bug is maybe because some of your floppy are silently failing, and it would work on one floppy but not one another, have you tried on different floppy disk?
User avatar
Chema
Game master
Posts: 3013
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: FloppyBuilder evolution

Post by Chema »

Yes Godzil. I tried with four different disks. Same problem. Silicebit also had problems with Pushing the Envelope, so it is a quite repeatable issue.

I have some news (rather good, I think). I decided to put some color bars on the bottom trying to detect the place where the bootloader was getting stuck. I altered the microdisc boot code as this: (COLOR is a macro - the same that appears in the loader.asm file).

Code: Select all

	;
	; Read sector data
	; 
	ldy #4
	sty retry_counter
read_sectors_loop

readretryloop
	nop
	nop
	nop
	
read_one_sector
	;
	; Check if we are on the correct track already and if not
	; then send a SEEK command to the FDC to move the head to
	; the correct track.
	;
	ldx #loader_track_position
	cpx FDC_track_register
	beq track_ok
	
	COLOR(1)
	; Write the track number in the FDC data register
	stx FDC_data

wait_drive2
	lda FDC_drq 				; We are waiting for the drive maybe not useful if drive is ready after the eprom boot
	bmi wait_drive2
	
	;
	; Send a SEEK command (change track)
	;
	lda #CMD_Seek
	sta FDC_command_register
	; 
	; Command words should only be loaded in the Command Register when the Busy status bit is off (Status bit 0). The one exception is the Force Interrupt command. 
	; Whenever a command is being executed, the Busy status bit is set. 
	; When a command is completed, an interrupt is generated and the busy status bit is reset. 
	; The Status Register indicates whethter the completed command encountered an error or was fault free. For ease of discussion, commands are divided into four types (I, II, III, IV).
	ldy #4
r_wait_completion
	dey
	bne r_wait_completion
r2_wait_completion
	lda FDC_status_register
	lsr
	bcs r2_wait_completion
	asl

track_ok	

	COLOR(2)
	; Write the sector number in the FDC sector register
__auto__sector_index
	lda #loader_sector_position
	sta FDC_sector_register ;
	
	; Interdire les IRQ du fdc ICI !
	;lda #%10000101 			; on force les le Microdisk en side0, drive A ... Set le bit de données !!!
	lda #%10000100 			; on force les le Microdisk en side0, drive A ... Set le bit de données !!!
	sta FDC_flags
			
	;
	; Send a READSECTOR command
	;
	lda #CMD_ReadSector
	sta FDC_command_register

	ldy #wait_status_floppy
waitcommand
	nop 					; Not useful but for old Floppy drive maybe
	nop 					; Not useful but for old Floppy drive maybe
	dey	
	bne waitcommand

	COLOR(3)
	;
	; Read the sector data
	;
	ldy #0
fetch_bytes_from_FDC
	lda FDC_drq
	bmi fetch_bytes_from_FDC
	lda FDC_data
__auto_write_address
	sta location_loader,y

	iny
	bne fetch_bytes_from_FDC
	; Done loading the sector
	
	lda FDC_status_register
	and #$1C
		
	beq sector_OK
	dec retry_counter
	bne readretryloop
	COLOR(4)
sector_OK
	inc __auto__sector_index+1
	inc __auto_write_address+2
	dec sector_counter
	bne read_sectors_loop

	COLOR(6)
	;
	; Data successfully loader (we hope)
	;
	sei
	lda #%10000001 			; Disable the FDC (Eprom select + FDC Interrupt request)
	sta FDC_flags
	
	ldx #FDC_OFFSET_MICRODISC
	jmp location_loader

Guess what happened? Yes. It worked. I reset a lot of times and it booted properly all of them but once, where it got stuck with a green bar. I guess in this loop:

Code: Select all

fetch_bytes_from_FDC
	lda FDC_drq
	bmi fetch_bytes_from_FDC
I also experienced a loading error later in the game once, but those are very rare I think. Certainly the loading code is not very robust when there are read errors, but that is a minor thing.

Basically the pha,lda,sta,pla set is adding enough cycles at the precise moment to allow the FDD to perform the operation or something like that.

As Barbitoric boots properly I am quite sure Dbug will be able to spot where to add those cycles ;)
User avatar
Chema
Game master
Posts: 3013
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: FloppyBuilder evolution

Post by Chema »

There is a small difference in the loading code between the "normal" sector reading and the booting routine. In the latter we have this:

Code: Select all

	;
	; Send a READSECTOR command
	;
	lda #CMD_ReadSector
	sta FDC_command_register

	ldy #wait_status_floppy
waitcommand
	nop 					; Not useful but for old Floppy drive maybe
	nop 					; Not useful but for old Floppy drive maybe
	dey	
	bne waitcommand

	COLOR(3)
	;
	; Read the sector data
	;
	ldy #0
fetch_bytes_from_FDC
	lda FDC_drq
	bmi fetch_bytes_from_FDC
	lda FDC_data
where the read command is set, then there is a small pause: the loop wait_status_floppy (30) times with a couple of nops. Then the COLOR macro I put which was not there before, then the code to read the sector data. In the normal (loader.asm code) read sector code the equivalent is:

Code: Select all

	lda #CMD_ReadSector
	sta FDC_command_register,y

	;cli
	jsr WaitCommand
	;sei

	;
	; Read the sector data
	;
	ldx #0
microdisc_read_data
	lda $0318
    bmi microdisc_read_data

	lda FDC_data,y
pretty similar where the WaitCommand is a subroutine implementing the above waiting loop. The difference is there is a jsr/rts involved, i.e. 12 additional cycles. The pha/lda/sta/pla code is 14 cycles. Could that be the difference between working and non-working?

Does anyone know the time that should be waited? Isn't there another way of checking when to proceed? Why is it necessary to wait anyway, when there is a loop reading FDC_drq and waiting for bit 7 to become low? Anyone who understands well how this works?
Godzil
Squad Leader
Posts: 774
Joined: Sat May 21, 2011 7:21 pm
Location: Between UK and France
Contact:

Re: FloppyBuilder evolution

Post by Godzil »

I will take a look at the read function later while working on the Cumulus Rev2 to see if there is anything that could be done better, especially on error management without penalty (unless all of that has been solved since ;))
jede
Flying Officer
Posts: 191
Joined: Tue Mar 14, 2006 11:53 am
Location: France

Re: FloppyBuilder evolution

Post by jede »

Hello,

I did this routine 15 years ago I can't remind how the FDC works. When i was coding it, i always tried it on real hardware (telestrat mainly) with 3 1/2 floppy drive.

The timing is really important : FDC/head have to finish the work. NOP are really important in the first routine release.

The only thing the original routine does not manage is the track/sectors errors. I wanted to do a routine which reads the fastest way a lot of data.
User avatar
Chema
Game master
Posts: 3013
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: FloppyBuilder evolution

Post by Chema »

Thanks Jede. Some difference may exist when booting and subsequent sector reads (?) because the code Fabrice wrote for 1337 (based on his code back from pinforic and Space:1999) did not have those waiting loops after the FDC commands.

You said you tested on a Telestrat btw? Do you know about the Telestrat controller bug that was discovered by Fabrice (there is an article on CEO-Mag about it, IIRC)? The thing was each time you wanted to access a register the instruction should be aligned so that the some low bits of the address of the code should match those on the address of the register in page 3.

That is why we filled the disk code with directives which added nop instructions ($ea) such as:

Code: Select all

.dsb (($0310&3)-((*+3)&3))&3,$ea
sta $0310
This bug is not emulated in Euphoric or Oricutron, of course, and was noticed by Fabrice when testing 1337 on a Telestrat.

BTW, Dbug, this means these floppies won't work on a Telestrat with the current code.
jede
Flying Officer
Posts: 191
Joined: Tue Mar 14, 2006 11:53 am
Location: France

Re: FloppyBuilder evolution

Post by jede »

Hello,

I know this problem, i discovered it last month. But as you said, i did the code on telestrat in 2001 thinking about a problem on my floppy drive ! :). but it's maybe the bug.

It's a bit hard to know how some chips works on telestrat, because there is one chip which do the work of the microdisc card, and we have no documentation on this chip.

1337 (oricium also) works on telestrat with stratoric cardridge. But Space 1999 does not start (it starts but it hangs), i still don't know why. I use HxC. I don't know yet if it's a HxC problem or a rom call
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: FloppyBuilder evolution

Post by Dbug »

Jonathan did use an Atmos with a Microdisc, I used the Pravetz with a Cumana Drive, and Jede used his Telestrat - and since he was the one who wrote the loading code originally I'm pretty sure our first demos worked fine on Telestrat!

Could people with Telestrat check if Quintessential and Barbitoric run fine?

If they do, either:
- we had an incredible luck and everything is aligned to perfection
- there's another way to bypass the telestrat bug which does not require special alignment (different delays, some weird controller bit flags, etc...)

Would be interesting to know :)
User avatar
Chema
Game master
Posts: 3013
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: FloppyBuilder evolution

Post by Chema »

jede wrote:Hello,
1337 (oricium also) works on telestrat with stratoric cardridge. But Space 1999 does not start (it starts but it hangs), i still don't know why. I use HxC. I don't know yet if it's a HxC problem or a rom call
Yes. The disk access in the stratoric cartridge is full of NOPs here and there for aligning the instructions. Evidently Fabrice Broche knew about the bug. Space:1999 does not do that, so it most probably fail when trying to read data into overlay ram. It boots because it is using Sedoric to boot. Once it switches to our own sector routines it fails.
Dbug wrote: - we had an incredible luck and everything is aligned to perfection
I have been checking and it is only the lower 2 bytes which need to be aligned, so it could be confused with needed wait cycles and inserting nops ended up making it work!
Fabrice wrote: Now my understanding is that there's a timing bug in the RE (Read), WR (Write) or CS (Chip Select) built by the ULAs, which drives the FDC 1793 chip. I think the timing is too long, so the signals still enable the FDC at the beginning of the next cpu cycle, which is the fetch of the [following] opcode. So the two LSB address lines (A0 and A1) of the [following] instruction are still selecting a register in the FDC.
Fabrice Frances went mad trying to debug 1337 with his Telestrat because every time he added something, the code seemed to fail in a different place.
Post Reply