sdcard i/o, what format, CHARROM/KICKSTART not loading

Ben-401

unread,

Aug 8, 2016, 8:42:35 AM8/8/16

to C65GS Development

Hi All:
Can anyone specify exactly how to get the sdcard format correct?
I have tried on vista, format FAT32, quick format, and although the bitfile gets read by the fpga hardware, the mega65-rom and other files cannot.
The error I get is that Kernal not found, looking for kernal, no kernal, trying to boot from lan, (or similar).
I have tried both 512 and 2048 allocation unit size.

My understanding is that 512 and 2048 sizes both work when the fpga reads in the bitfile, but there is a problem when reading in the ROM files and KICKUP.M65 files. This is likely caused by the current sdcardio (vhdl component) implementation.

Seems the sdcardio.vhdl does not correctly read from certain format of cards. Or is it the size/type of card?

I will be looking into this issue with a view to:
- identify exactly what type of format the scdard needs to be (if any),
- modify the vhdlio code to correctly read (if required),
- implement write
- and get into a position where the hypervisor-traps do as they are supposed to do to allow the functionality we require, like:
= load files using native c64 kernal routines at normal slow speeds
= fast load using our special mega routines
= further functionality as defined for the c65/mega65 environments.

Paul Gardner-Stephen

unread,

Aug 8, 2016, 1:24:23 PM8/8/16

to Ben-401, C65GS Development

Hello,

On Mon, Aug 8, 2016 at 10:12 PM, Ben-401 <ben.0...@gmail.com> wrote:

Hi All:
Can anyone specify exactly how to get the sdcard format correct?
I have tried on vista, format FAT32, quick format, and although the bitfile gets read by the fpga hardware, the mega65-rom and other files cannot.
The error I get is that Kernal not found, looking for kernal, no kernal, trying to boot from lan, (or similar).
I have tried both 512 and 2048 allocation unit size.

My understanding is that 512 and 2048 sizes both work when the fpga reads in the bitfile, but there is a problem when reading in the ROM files and KICKUP.M65 files. This is likely caused by the current sdcardio (vhdl component) implementation.

The bitstream is read using a simple FAT32 implementation in a PIC on the Nexys4 board, over which we have no control. The ROMs etc are read using our sdcardio + Kickstart FAT32 implementation. It is almost certainly the Kickstart FAT32 implementation that is the problem. I'm suspecting it might be an LBA / CHS issue. We can add checkpoint debug messages to the kickstart implementation to try to debug the situation.

These problems are also part of why we are signing on a new student to implement an FDISK+FORMAT command natively on the MEGA65, so that people can prepare their cards more easily.

Also, I think someone else is beginning to work on the SD/SDHC card issue? We REALLY need to start tagging issues on github.com/MEGA65/mega65-core to keep track of who is doing what. If everyone who is working on something can create an issue for what they are working on, and then assign it to themselves (or poke me if you can't self-assign), that would be really helpful, if we are going to proceed efficiently and without duplicating one another's efforts.

Seems the sdcardio.vhdl does not correctly read from certain format of cards. Or is it the size/type of card?

I will be looking into this issue with a view to:
- identify exactly what type of format the scdard needs to be (if any),
- modify the vhdlio code to correctly read (if required),

This should be fine.

- implement write

This already works from the SD card interface, the writing bugs are in the F011 emulation. This just needs debugging (particularly around the buffer window register). I can provide some guidance on this. We can also fairly readily write a test for this that we can use to understand and verify the misbehaviour, and thus also know when we have it right.

- and get into a position where the hypervisor-traps do as they are supposed to do to allow the functionality we require, like:
= load files using native c64 kernal routines at normal slow speeds
= fast load using our special mega routines
= further functionality as defined for the c65/mega65 environments.

This last part can be done already, once we have a card properly prepared, as it only requires read-access for fast loading. We just need to think about how we wedge the fast load routines in. This will probably be a kickstart freeze menu option, similar to on the action reply ("reset with fast loader" / "normal reset" etc).

Alternatively we could make patches for the C65 ROM to achieve this, and pick between which ROM we boot with (already implemented by holding down 0 through 9 on reset).

Paul.

--
You received this message because you are subscribed to the Google Groups "C65GS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-development+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Gurce Isikyildiz

unread,

Aug 8, 2016, 5:02:55 PM8/8/16

to Paul Gardner-Stephen, Ben-401, C65GS Development

Hi guys,

Well, I suppose I was looking into an issue of the kernal failing to load properly off my sd-card. That's what spawned off the desire for better debugging facilities via the m65dbg tool, to help track this sort of thing down easier.

That being said, I'm fine with not taking complete ownership of the issue. If others feel they've got more knowledge in this area and can get to the bottom of this faster, then go right ahead.

This is still early days for me on this project, so I'm content with chasing this up at my learner's pace.

Anyway, I'll put my name down in the issue tracker for now, but if someone else wants to step in, go right ahead.

Gurce

Ben-401

unread,

Aug 10, 2016, 7:59:55 AM8/10/16

to C65GS Development, pa...@servalproject.org, ben.0...@gmail.com

Hi Gurce,
I seem to be having a few unrelated problems, and its difficult to know where to start looking.
for example, maybe the bootlogo not being displayed correctly is due to it not being read from the SDcard properly, and also when I load a KICKUP file it seems to screw up the screen display.
And you not being able to load kernals etc.
And:
Currently we have three SDcard's in the lab, but only one will allow ROM files to be read from the mega65 firmware. Bitstreams are read off each card OK, but the firmware cannot read from the two other cards.
So for me this is a showstopper, especially when we have a multiuser environment in the lab.
And for new people coming on board, if they go to the trouble of purchasing Nexys, clone repo, etc, etc, then dont know how to format the card (either do we), they cannot see the project on their nexys board.

I will put up my hand on this issue. There is lots to learn and hopefully with your new m65dbg tool I can be able to see what is in memory compared to what is on the card.

Gurce Isikyildiz

unread,

Aug 10, 2016, 8:07:09 AM8/10/16

to Ben-401, C65GS Development, Paul Gardner-Stephen

Yep, I hear where you're coming from on this, and I agree, it's a nasty showstopper.

After reading about your need to compare what's in memory with what's in the original file, it makes me itch to add the load/save commands into the debugger.

I've made an issue for this here and will add these commands in soon:

https://github.com/MEGA65/m65dbg/issues/4

Hopefully once they're added, you will be able to easily save out a dump of memory straight to a file on your pc and compare it against the original.

Gurce

Paul Gardner-Stephen

unread,

Aug 10, 2016, 8:45:03 AM8/10/16

to Gurce Isikyildiz, Ben-401, C65GS Development

Hello,

I am thinking that CHS/LBA mode for the disk partitioning might be a factor with the format problems.

Paul.

Gurce Isikyildiz

unread,

Aug 15, 2016, 6:51:04 AM8/15/16

to C65GS Development, gurce.is...@gmail.com, ben.0...@gmail.com, pa...@servalproject.org

I thought I'd take m65dbg for a test-drive tonight to look into reasons for why it had that corrupted segment from: Range: 0036200 <--> 0036FFF, a diff of the issue is shown here:

https://groups.google.com/d/msg/c65gs-development/q7kCars2Xqw/a_WIWMmcAgAJ

I tried to step through the code until that region was reached:

---------------------------------------
#1: DWORD   dos_file_loadaddress: 00036200
#2: WORD    dos_sectorsread: 00B1
#3: STRING  dos_requested_filename: MEGA65.ROM
#4: WORD    file_pagesread: 0010
#5: BYTE    dos_current_file_descriptor: 01
#6: DWORD   dos_current_cluster: 000003C2
#7: DWORD   dos_current_sector: 000003C1
#8: BYTE    dos_current_sector_in_cluster: 00
#9: BYTE    dos_disk_table_offset: 00
---------------------------------------
> /Users/gurce/c64/mega65/mega65/kickstart_dos.a65:2209
> 2199:
> 2200: drfim_sector_loop:
> 2201:     jsr dos_file_read_current_sector
> 2202:     bcc drfim_eof
> 2203:
> 2204:     ; copy sector to memory
> 2205:     ldx #$00
> 2206:     ldz #$00
> 2207: drfim_rr1:
> 2208:     lda $de00,x
> 2209:     nop ; 32-bit pointer access follows
...
> 2229:     ; that eventually overwrites the hypervisor and results in privilege
> 2230:     ; escalation.
> 2231:     inw <dos_file_loadaddress+1
> 2232:
> 2233:     ; Increment number of sectors read (16 bit valie)
> 2234:     inc dos_sectorsread
> 2235:     bne drfim_sector_loop
> 2236:     inc dos_sectorsread+1
> 2237:     ; see if there is another sector
> 2238:     bne drfim_sector_loop

I'll try break just prior to this drfim_sector_loop call... I'll use the inc call, which is at this pc:

$8FDB      M_nnnn:2 EE A9 BC INC $BCA9

So, I'll break at "break 8fdb"... Yeah, I did "t0" and "dis" multiple times until I saw:

#1: DWORD   dos_file_loadaddress: 00036200

Once I saw this, it meant that this loop was about to read the faulty sector in question...

So then, after the call to "jsr dos_file_read_current_sector" I saw that the memory at this point usually equates to the sector that was read:

<dbg>dump de00 200
:777DE00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:777DE10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:777DE20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:777DE30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:777DE40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:777DE50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:777DE60 00 00 00 00 00 00 00 00 FF FF FF FF FF FF FF FF | ........????????
:777DE70 FF FF 00 00 FF FF FF FF 00 00 FF FF FF FF 00 00 | ??..????..????..
:777DE80 FF FF FF FF 00 00 FF FF FF FF FF FF FF FF FF FF | ????..??????????
:777DE90 FF FF FF FF FF FF FF FF FF FF 00 00 FF FF FF FF | ??????????..????
:777DEA0 00 00 FF FF FF FF 00 00 FF FF FF FF 00 00 FF FF | ..????..????..??
:777DEB0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF | ????????????????
:777DEC0 FF FF 00 00 FF FF FF FF 00 00 FF FF FF FF 00 00 | ??..????..????..
:777DED0 FF FF FF FF 00 00 FF FF FF FF FF FF FF FF FF FF | ????..??????????
:777DEE0 00 00 00 00 FF FF FF FF FF FF FF FF FF FF 00 00 | ....??????????..
:777DEF0 FF FF FF FF 00 00 FF FF FF FF 00 00 FF FF FF FF | ????..????..????
:777DF00 00 00 FF FF FF FF FF FF FF FF FF FF 00 00 00 00 | ..??????????....
:777DF10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:777DF20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:777DF30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:777DF40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:777DF50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:777DF60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:777DF70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:777DF80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:777DF90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:777DFA0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:777DFB0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:777DFC0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:777DFD0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:777DFE0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:777DFF0 00 00 00 00 00 00 00 00 00 00 00 00 FF FF FF FF | ............????
This is instead telling me that only garbage was read within this call to "jsr dos_file_read_current_sector"

Well, I haven't got the cause, but at least I seem to be honing in on the area in need of investigation...

I think on my next attempt, I need to dig deeper inside dos_file_read_current_sector and see why it screws up for this particular sector...

Gurce

Paul Gardner-Stephen

unread,

Aug 15, 2016, 7:20:16 AM8/15/16

to Gurce Isikyildiz, C65GS Development, Ben-401

Hello,

Good detective work.

What is the content of $D681-$D684 before it loads the wrong sector?

My gut feeling is that it is messing up when it increments the sector offset within a cluster at some awkward boundary point, i.e., something in:

; Add sector within cluster

jsr dos_get_file_descriptor_offset

bcc dos_return_error_already_set

ora #dos_filedescriptor_offset_sectorincluster

tay

ldx #$00

clc

lda dos_file_descriptors,y

bne dfrcs4

dfrcs2: lda #$00

dfrcs4:

adc $d681,x

sta $d681,x

bcc dfrcs_inced

inx

cpx #$04

bne dfrcs2

dfrcs_inced:

I'm currently going through and commenting that routine. My best guess is that I have screwed up the carry logic some how.

But let me know what you discover...

Paul.

Gurce Isikyildiz

unread,

Aug 15, 2016, 8:11:09 AM8/15/16

to Paul Gardner-Stephen, C65GS Development, Ben-401

Hi Paul,

Okidoke, after your suggestion, I thought I'd have another stab at it, focusing on $d681... Here are my notes:

Will mull this over and try again :)

This time, I'll do a "break loadc65rom"
Reset the machine with restore-key for 3 sec
The breakpoint will trigger
Then do "break 8fdb"
Then do lots of "t0" and "dis" until we get to this point again:
```
#1: DWORD   dos_file_loadaddress: 00036200
```
Upon that, do a dump of d681...
Actually, since it is a dword, we can watch it with "wd d681"
Here are the sort of values as I step through:
- #1: DWORD dos_file_loadaddress: 00020400
  #10: DWORD d681: 007CA000
- #1: DWORD dos_file_loadaddress: 00020600
  #10: DWORD d681: 007CA200
- #1: DWORD dos_file_loadaddress: 00020800
  #10: DWORD d681: 007CA400
- #1: DWORD dos_file_loadaddress: 00036000
  #10: DWORD d681: 007DFE00
I think the genuine point where the $d681 dword value is completely calculated is at:

break sd_readsector
Anyway, I got to the "drfim_sector_loop" label, with var values of:

#1: DWORD dos_file_loadaddress: 00036200
#10: DWORD d681: 007DFE00
I'll now carefully step into "jsr dos_file_read_current_sector" to try figure out what's happening...
- After the call to "jsr dos_cluster_to_sector", we have:
  #10: DWORD d681: 00003EFF
- After the "jsr sd_fix_sectornumber" loop, we have:
  #10: DWORD d681: 007C0000

Hmm, so something weird occurred inside the call to sd_fix_sectornumber?

Gurce

Paul Gardner-Stephen

unread,

Aug 15, 2016, 8:28:53 AM8/15/16

to Gurce Isikyildiz, C65GS Development, Ben-401

Hello,

Can you log the cluster number, sector number in cluster, and then the resulting sector number and sector offset for each sector read? If you can do that for every sector read, so that we can see it in the lead up to, and immediately following when it goes west, that would be great to help us understand exactly how it is miscalculating, and where the miscalculation is. For example, if the cluster numbers count up in order, but the sector address suddenly jumps, we know we have a problem in clustertosector.

Paul.

Gurce Isikyildiz

unread,

Aug 15, 2016, 8:55:21 AM8/15/16

to Paul Gardner-Stephen, C65GS Development, Ben-401

Ok, here's a few entries preceeding it getting to dos_file_loadaddress 36200 and once it hits, and a bit after:

---------------------------------------
#1: DWORD dos_file_loadaddress: 00020400
#2: WORD dos_sectorsread: 0002

#3: STRING dos_requested_filename: MEGA65.ROM
#4: WORD file_pagesread: 0010
#5: BYTE dos_current_file_descriptor: 01

#6: DWORD dos_current_cluster: 000003AC
#7: DWORD dos_current_sector: 000003CC

#8: BYTE dos_current_sector_in_cluster: 00
#9: BYTE dos_disk_table_offset: 00

#10: DWORD   d681: 007CA000
---------------------------------------
#1: DWORD   dos_file_loadaddress: 00020600
#2: WORD    dos_sectorsread: 0003

#3: STRING dos_requested_filename: MEGA65.ROM
#4: WORD file_pagesread: 0010
#5: BYTE dos_current_file_descriptor: 01

#6: DWORD dos_current_cluster: 000003AC
#7: DWORD dos_current_sector: 000003CC

#8: BYTE dos_current_sector_in_cluster: 00
#9: BYTE dos_disk_table_offset: 00

#10: DWORD   d681: 007CA200
---------------------------------------
#1: DWORD   dos_file_loadaddress: 00020800
#2: WORD    dos_sectorsread: 0004

#3: STRING dos_requested_filename: MEGA65.ROM
#4: WORD file_pagesread: 0010
#5: BYTE dos_current_file_descriptor: 01

#6: DWORD dos_current_cluster: 000003AC
#7: DWORD dos_current_sector: 000003CC

#8: BYTE dos_current_sector_in_cluster: 00
#9: BYTE dos_disk_table_offset: 00

#10: DWORD   d681: 007CA400
---------------------------------------
....
---------------------------------------
#1: DWORD   dos_file_loadaddress: 00035A00
#2: WORD    dos_sectorsread: 00AD

#3: STRING dos_requested_filename: MEGA65.ROM
#4: WORD file_pagesread: 0010
#5: BYTE dos_current_file_descriptor: 01

#6: DWORD dos_current_cluster: 000003C1
#7: DWORD dos_current_sector: 000003C0

#8: BYTE dos_current_sector_in_cluster: 00
#9: BYTE dos_disk_table_offset: 00

#10: DWORD   d681: 007DF600
---------------------------------------
#1: DWORD   dos_file_loadaddress: 00035C00
#2: WORD    dos_sectorsread: 00AE

#3: STRING dos_requested_filename: MEGA65.ROM
#4: WORD file_pagesread: 0010
#5: BYTE dos_current_file_descriptor: 01

#6: DWORD dos_current_cluster: 000003C1
#7: DWORD dos_current_sector: 000003C0

#8: BYTE dos_current_sector_in_cluster: 00
#9: BYTE dos_disk_table_offset: 00

#10: DWORD   d681: 007DF800
---------------------------------------
#1: DWORD   dos_file_loadaddress: 00035E00
#2: WORD    dos_sectorsread: 00AF

#3: STRING dos_requested_filename: MEGA65.ROM
#4: WORD file_pagesread: 0010
#5: BYTE dos_current_file_descriptor: 01

#6: DWORD dos_current_cluster: 000003C1
#7: DWORD dos_current_sector: 000003C0

#8: BYTE dos_current_sector_in_cluster: 00
#9: BYTE dos_disk_table_offset: 00

#10: DWORD   d681: 007DFA00
---------------------------------------
#1: DWORD   dos_file_loadaddress: 00036000
#2: WORD    dos_sectorsread: 00B0

#3: STRING dos_requested_filename: MEGA65.ROM
#4: WORD file_pagesread: 0010
#5: BYTE dos_current_file_descriptor: 01

#6: DWORD dos_current_cluster: 0000032A

#7: DWORD   dos_current_sector: 000003C1
#8: BYTE    dos_current_sector_in_cluster: 00
#9: BYTE    dos_disk_table_offset: 00

#10: DWORD d681: 00065400

---------------------------------------
#1: DWORD   dos_file_loadaddress: 00036200
#2: WORD    dos_sectorsread: 00B1
#3: STRING dos_requested_filename: MEGA65.ROM
#4: WORD    file_pagesread: 0010
#5: BYTE    dos_current_file_descriptor: 01
#6: DWORD   dos_current_cluster: 000003C2
#7: DWORD   dos_current_sector: 000003C1
#8: BYTE    dos_current_sector_in_cluster: 00
#9: BYTE    dos_disk_table_offset: 00

#10: DWORD   d681: 007DFE00
---------------------------------------
#1: DWORD   dos_file_loadaddress: 00036400
#2: WORD    dos_sectorsread: 00B2

#3: STRING dos_requested_filename: MEGA65.ROM
#4: WORD    file_pagesread: 0010
#5: BYTE    dos_current_file_descriptor: 01
#6: DWORD   dos_current_cluster: 000003C2
#7: DWORD   dos_current_sector: 000003C1
#8: BYTE    dos_current_sector_in_cluster: 00
#9: BYTE    dos_disk_table_offset: 00

#10: DWORD   d681: 007C0000
---------------------------------------
#1: DWORD   dos_file_loadaddress: 00036600
#2: WORD    dos_sectorsread: 00B3

#3: STRING dos_requested_filename: MEGA65.ROM
#4: WORD    file_pagesread: 0010
#5: BYTE    dos_current_file_descriptor: 01
#6: DWORD   dos_current_cluster: 000003C2
#7: DWORD   dos_current_sector: 000003C1
#8: BYTE    dos_current_sector_in_cluster: 00
#9: BYTE    dos_disk_table_offset: 00

#10: DWORD   d681: 007C0200
---------------------------------------
#1: DWORD   dos_file_loadaddress: 00036800
#2: WORD    dos_sectorsread: 00B4

#3: STRING dos_requested_filename: MEGA65.ROM
#4: WORD    file_pagesread: 0010
#5: BYTE    dos_current_file_descriptor: 01
#6: DWORD   dos_current_cluster: 000003C2
#7: DWORD   dos_current_sector: 000003C1
#8: BYTE    dos_current_sector_in_cluster: 00
#9: BYTE    dos_disk_table_offset: 00

#10: DWORD   d681: 007C0400
---------------------------------------
#1: DWORD   dos_file_loadaddress: 00036A00
#2: WORD    dos_sectorsread: 00B5

#3: STRING dos_requested_filename: MEGA65.ROM
#4: WORD    file_pagesread: 0010
#5: BYTE    dos_current_file_descriptor: 01
#6: DWORD   dos_current_cluster: 000003C2
#7: DWORD   dos_current_sector: 000003C1
#8: BYTE    dos_current_sector_in_cluster: 00
#9: BYTE    dos_disk_table_offset: 00

#10: DWORD   d681: 007C0600
---------------------------------------
#1: DWORD   dos_file_loadaddress: 00036C00
#2: WORD    dos_sectorsread: 00B6

#3: STRING dos_requested_filename: MEGA65.ROM
#4: WORD    file_pagesread: 0010
#5: BYTE    dos_current_file_descriptor: 01
#6: DWORD   dos_current_cluster: 000003C2
#7: DWORD   dos_current_sector: 000003C1
#8: BYTE    dos_current_sector_in_cluster: 00
#9: BYTE    dos_disk_table_offset: 00

#10: DWORD   d681: 007C0800
---------------------------------------
#1: DWORD   dos_file_loadaddress: 00036E00
#2: WORD    dos_sectorsread: 00B7

#3: STRING dos_requested_filename: MEGA65.ROM
#4: WORD    file_pagesread: 0010
#5: BYTE    dos_current_file_descriptor: 01
#6: DWORD   dos_current_cluster: 000003C2
#7: DWORD   dos_current_sector: 000003C1
#8: BYTE    dos_current_sector_in_cluster: 00
#9: BYTE    dos_disk_table_offset: 00

#10: DWORD   d681: 007C0A00
---------------------------------------
#1: DWORD   dos_file_loadaddress: 00037000
#2: WORD    dos_sectorsread: 00B8

#3: STRING dos_requested_filename: MEGA65.ROM
#4: WORD file_pagesread: 0010
#5: BYTE dos_current_file_descriptor: 01

#6: DWORD dos_current_cluster: 0000032A
#7: DWORD dos_current_sector: 000003C2

#8: BYTE dos_current_sector_in_cluster: 00
#9: BYTE dos_disk_table_offset: 00

#10: DWORD   d681: 00065400
---------------------------------------
#1: DWORD   dos_file_loadaddress: 00037200
#2: WORD    dos_sectorsread: 00B9

#3: STRING dos_requested_filename: MEGA65.ROM
#4: WORD file_pagesread: 0010
#5: BYTE dos_current_file_descriptor: 01

#6: DWORD dos_current_cluster: 000003C3
#7: DWORD dos_current_sector: 000003C2

#8: BYTE dos_current_sector_in_cluster: 00
#9: BYTE dos_disk_table_offset: 00

#10: DWORD   d681: 007E0E00
---------------------------------------
#1: DWORD   dos_file_loadaddress: 00037400
#2: WORD    dos_sectorsread: 00BA

#3: STRING dos_requested_filename: MEGA65.ROM
#4: WORD file_pagesread: 0010
#5: BYTE dos_current_file_descriptor: 01

#6: DWORD dos_current_cluster: 000003C3
#7: DWORD dos_current_sector: 000003C2

#8: BYTE dos_current_sector_in_cluster: 00
#9: BYTE dos_disk_table_offset: 00

#10: DWORD d681: 007E1000

Gurce

Gurce Isikyildiz

unread,

Aug 15, 2016, 4:47:50 PM8/15/16

to Paul Gardner-Stephen, C65GS Development, Ben-401

Debugging some more this morning, in an effort to get more familiar with this section of the code. I was stepping through this chunk and wasn't sure what it was trying to achieve:

> 1094: multipliedclusternumber:
> 1095:     ldx #$00
> 1096: mmm1:    lda $d681,x
> 1097:     inx
> 1098:     cpx #$04
> 1099:     bne mmm1

It just seems to read the values from $d681-$d683, but doesn't do anything with them? Maybe it had a payload once, but it got scrapped?

Anyway, I'll press on with the debugging, feels like we're edging temptingly close to the root-cause... :)

Gurce

Paul Gardner-Stephen

unread,

Aug 15, 2016, 6:08:55 PM8/15/16

to Gurce Isikyildiz, C65GS Development, Ben-401

Hello,

It was probably originally used in some sort of debug output. You are right that it appears to be a vestigal appendix right now however, and can be deleted.

Paul.

Gurce Isikyildiz

unread,

Aug 16, 2016, 9:10:44 AM8/16/16

to Paul Gardner-Stephen, C65GS Development, Ben-401

Hi Paul,

I didn't get a chance to assess the sd-card's contents (I was too lazy to remove it from the nexys board, hehehe :D).

But still, I think I hit some paydirt tonight. While stepping through, I noticed when I added a break early inside sd_fix_sectornumber somewhere, I saw this on successive hits at the point where the prob happens:

#1: DWORD   dos_file_loadaddress: 00036000
#9: DWORD   d681: 00003EFF

...and then next iteration:

#1: DWORD   dos_file_loadaddress: 00036200
#9: DWORD   d681: 00003E00

Whoa, the dword(d681) value didn't increment properly!

Taking a look at the point in the code responsible, I tracked it down to the following bit inside "kickstart_dos.a65:1923":

dfrcs4:                  ; x = 0, a = 01, dword(d681) = 00003EFF
        adc $d681,x      ; a = 00, carry-flag set
        sta $d681,x      ; dword(d681) = 00003E00
        bcc dfrcs_inced  ; carry-flag is set, so no jump
        inx              ; x = 1
        cpx #$04         ; carry-flag is reset!
        bne dfrcs2

I.e.:

in the first iteration of this loop, the adc call does 1+ff = 0 (carry-set).
the hope is that this carry-flag will be part of the adc in the next iteration
unfortunately, the cpx call is resetting the carry-flag :(

Not sure what your preferred way to fix is? To expand out the entire loop and avoid the cpx? Or perhaps there are better ways? I'm not so savvy with the 6502 assembly world (as much as I hope to be one day!), so I'd better leave it in your hands :)

Gurce

Paul Gardner-Stephen

unread,

Aug 16, 2016, 11:06:58 AM8/16/16

to Gurce Isikyildiz, C65GS Development, Ben-401

As I have just commented on the issue, the following may be a solution:

dos_file_read_current_sector:

jsr dos_set_current_cluster_from_file

jsr dos_cluster_to_sector

; Add sector within cluster

jsr dos_get_file_descriptor_offset

bcc dos_return_error_already_set

ora #dos_filedescriptor_offset_sectorincluster

tay

ldx #$00

clc

php

lda dos_file_descriptors,y

bne dfrcs4

dfrcs2: lda #$00

dfrcs4: plp

adc $d681,x

sta $d681,x

bcc dfrcs_inced

php

inx

cpx #$04

bne dfrcs2

plp

dfrcs_inced:

Gurce Isikyildiz

unread,

Aug 16, 2016, 5:49:08 PM8/16/16

to Paul Gardner-Stephen, C65GS Development, Ben-401

Cheers Paul. I've given that a try now. Some good-ish now, putting it briefly, I believe it has resolved the issue. On the downside, I tried using the KICKUP.M65 technique to upload the newly compiled kickstartc65gs.bin binary and that seemed to have problems loading. I had to break at the "already kicked" test, then use the "g<addr>" command to force the new KICKUP.M65 file to load. After doing so however, all was fine and dandy, it boots to basic just fine, and a save of memory between 0x20000-0x40000 matches the MEGA65.ROM file :)

Gurce

Paul Gardner-Stephen

unread,

Aug 16, 2016, 6:19:16 PM8/16/16

to Gurce Isikyildiz, C65GS Development, Ben-401

Hello,

Excellent!

Time for us to make a new bitstream incorporating it, then.

Paul.

Gurce Isikyildiz

unread,

Aug 18, 2016, 4:38:09 PM8/18/16

to C65GS Development, gurce.is...@gmail.com, ben.0...@gmail.com, pa...@servalproject.org

Cool :)

Just wondering, is the failure to load up the KICKUP.M65 file on boot-up of any concern? Is it worth investigating? Or should I let it go for now and perhaps focus on the load/save commands for m65dbg? My gut says you'll want the latter, but still, there's this itch inside me to figure out what went wrong with the mechanism to auto-load KICKUP.M65. But who knows, once the 'load' command works, perhaps it'll end up being more convenient dumping new binaries across that way (rather than taking the sd-card out, copying files across, putting sd-card in).

Gurce

Paul Gardner-Stephen

unread,

Aug 18, 2016, 9:14:09 PM8/18/16

to Gurce Isikyildiz, C65GS Development, Ben-401

Hello,

On Fri, Aug 19, 2016 at 6:08 AM, Gurce Isikyildiz <gurce.is...@gmail.com> wrote:

Cool :)

Just wondering, is the failure to load up the KICKUP.M65 file on boot-up of any concern? Is it worth investigating? Or should I let it go for now and perhaps focus on the load/save commands for m65dbg? My gut says you'll want the latter, but still, there's this itch inside me to figure out what went wrong with the mechanism to auto-load KICKUP.M65. But who knows, once the 'load' command works, perhaps it'll end up being more convenient dumping new binaries across that way (rather than taking the sd-card out, copying files across, putting sd-card in).

While we have fixed one problem with loading files from the SD card, I believe that at least one more still remains. By all means try to investigate and fix that.

Make sure you build a bitstream from the head of the development branch at github.com/mega65/mega65-core, so that you have the fixes so far included.

Paul.

Gurce Isikyildiz

unread,

Aug 19, 2016, 5:15:16 PM8/19/16

to C65GS Development, gurce.is...@gmail.com, ben.0...@gmail.com, pa...@servalproject.org

Okidoke, I'm working towards switching to the latest bitstream/branch, there's just a few issues I need to sort out with running "compile.sh" in my windows/cygwin environment (sourcing the cbmconvert and xst programs).

Till I've got them sorted out, I'll try make do with my present/older bitstream.

One observation in my debugging of the failed loading of the KICKUP.M65 issue was as follows.

I set a breakpoint around "logook:" and did a reset:

logook:
                ; iterate through directory entries looking for ordinary file
                ; KICKUP.M65 to load into hypervisor memory ...
                ; ... but only if we are not running a kick-up'd kickstart now.
                lda $d67e
                beq nextdirectoryentry3

So this $d67e address is used like a flag to detect if we are presently running from a KICKUP.M65 already?

When it broke here after my reset, I saw:

<dbg>pb d67e
d67e: FF

So the flag is either FF or 0 then? The "beq nextdirectoryentry3" call seems to imply that 0 means we haven't kicked from a KICKUP.M65 before, and non-zero means we have.

The only other point I saw this $d67e address touched was within "kickuproutine:":

kickuproutine:
                ; The following routine gets copied as-is to $3000 and run from there.
                ; The DMA list is still available in the kickstart ROM when it gets
                ; called, so we can just use it there, instead of working out where
                ; it gets copied to

                ; Set bottom 22 bits of DMA list address as for C65
                ; (8MB address range). Kickstart ROM is at $FFF8000, so $FF goes
                ; in high-byte area
                lda #$ff
                sta $d702
                lda #$ff
                sta $d704 ; dma list is in top MB of address space
                sta $d706 ; similarly destination of copy is top MB of address space
                lda #$00
                sta $d705 ; source of copy is bottom MB of address space
                lda #>kickupdmalist
                sta $d701
                lda #<kickupdmalist
                sta $d700
                ; clear source/destination MB so that C65 ROM doesn't go bananas
                lda #$00
                sta $d706

; copy complete, so mark ourselves upgraded, and jump into hypervisor
; as though we were just reset.

sta $d67e ; mark ourselves as having kicked up
jmp $8100

But here, it sets it to zero and comment implies that setting it to zero equates to being 'kicked up'? Does this mismatch with the use of the flag implied by "beq nextdirectoryentry3"?

Also, it got me wondering, is there a way to pause the cpu into trace mode incredibly early via one of the nexys board's switches? I was thinking, if so, I could switch it to trace mode incredibly early, set my "break logook" breakpoint, and see how the code flows upon the first iteration of this code (and not just after the reset, as I'm doing now).

Gurce

Paul Gardner-Stephen

unread,

Aug 19, 2016, 6:05:14 PM8/19/16

to Gurce Isikyildiz, C65GS Development, Ben-401

Hello,

On Sat, Aug 20, 2016 at 6:45 AM, Gurce Isikyildiz <gurce.is...@gmail.com> wrote:

Okidoke, I'm working towards switching to the latest bitstream/branch, there's just a few issues I need to sort out with running "compile.sh" in my windows/cygwin environment (sourcing the cbmconvert and xst programs).

Till I've got them sorted out, I'll try make do with my present/older bitstream.

You could also install Ubuntu in a VirtualBox (or pick another free VM host), and do the building from there.

Ok, you do have an old bitstream, then :) There was a significant bug that affected that and a bunch of other issues. I'll get you the latest bitstream that I am running (which we will also release more generally in the near future).

Also, it got me wondering, is there a way to pause the cpu into trace mode incredibly early via one of the nexys board's switches? I was thinking, if so, I could switch it to trace mode incredibly early, set my "break logook" breakpoint, and see how the code flows upon the first iteration of this code (and not just after the reset, as I'm doing now).

Yes, I don't remember which switch it is, but it forces the machine into single-step mode whenever it is on. Maybe 8 or 9 or 11. There is only 16 to try ;)

Gurce Isikyildiz

unread,

Aug 19, 2016, 6:11:52 PM8/19/16

to Paul Gardner-Stephen, C65GS Development, Ben-401

Cheers for the newer bitstream Paul, I'll give that a try now :)

I did have an OpenSUSE vbox on my system too, was just a bit lazy to jump around :)

I finally did manage to overcome those obstacles within cygwin (i'll commit/push them later) and a new synthesis is underway.

Still, for now, it'll be much quicker to use your bitstream. I'll try those switches soon!

Ben-401

unread,

Aug 20, 2016, 6:12:39 AM8/20/16

to C65GS Development, pa...@servalproject.org, ben.0...@gmail.com

Hi Guys,

Well done Gurce for finding another "abnormality". These findings are worth their weight in gold. And I love your methadology!
As for the compile-script, yes is it recently updated to remove the dependancy on cbmconvert. Please refer to the 'builder" branch opposed to head-of-development for this change.
I am interested to know what changes you may push to "overcome your cygwin issue", but i think best to do that in another thread.
Sorry I dont know what switch does the single-step.

Looks like we are getting much closer to being able to load a KICKUP from the SDCARD !!
Yaa-Hoo (rubbing hands together...)

Gurce Isikyildiz

unread,

Aug 20, 2016, 7:00:14 PM8/20/16

to C65GS Development, pa...@servalproject.org, ben.0...@gmail.com

Thanks Ben, glad you enjoyed the fix :)

Yesterday, I finally managed to switch to the newer bitstream, I'll jot down a few of my notes here:

I managed to install cbmconvert within windows/cygwin via the steps you provided here:
- https://github.com/MEGA65/mega65-core/blob/development/doc/using.md
To get "compile.sh" working within cygwin, I added the following to it:

Alrighty then, I've fixed the unfound xst via tweaking the "compile.sh" as follows:

# here we need to detect if you have 32 or 64 bit machine
# on a 32-bit installation, only the settings32 exists.
# on a 64-bit installation, both 32 and 64 bit settings files exist.
if [ -e /opt/Xilinx/14.7/ISE_DS/settings64.sh ]; then
echo "Detected 64-bit Xilinx installation"
source /opt/Xilinx/14.7/ISE_DS/settings64.sh
elif [ -e /opt/Xilinx/14.7/ISE_DS/settings32.sh ]; then
echo "Detected 32-bit Xilinx installation"
source /opt/Xilinx/14.7/ISE_DS/settings32.sh
elif [ -e /cygdrive/c/Xilinx/14.7/ISE_DS/settings32.bat ]; then
echo "Detected 32-bit Xilinx installation (Windows/Cygwin)"
# source /cygdrive/c/Xilinx/14.7/ISE_DS/settings32.bat
PATH=$PATH:/cygdrive/c/Xilinx/14.7/ISE_DS/ISE/bin/nt/
else
echo "Cannot detect a Xilinx installation"
exit 0;
fi

I initially tried the "source .../settings32.bat" technique, but it didn't work so well inside cygwin. So I commented out that attempt, and just tried adding in the path that points to "xst.exe"
Hmm, I'm not sure as yet of the etiquette of working collaboratively in teams with git. In the past, I only ever used git in isolation, just me doing my own thing. But now, I'm a bit hesitant on how I should go about committing/pushing things without stepping on other people's toes :D How does it work? Do I make my own branch, commit there, and then at some stage ask if it's ok to merge back to main? I probably should read up on more git literature on this topic, but still, if anyone has a few suggestions on this, I'm open to hearing you out on it.
I tried out Paul's newer bit-stream, and my newer bit-stream, both seemed to load the MEGA65.ROM into memory without any problems, great to see!
Surprisingly to me (but I think Paul had a gut feeling on this), these newer bit-streams were also able to automatically load up the optional KICKUP.M65 file too! Good stuff, glad I don't need to stress/fret over that anymore :)
I had a hunt around for which switch will permit the hardware to boot-up straight into trace-mode.
I discovered that switch 11 forces trace mode on (you can use this either to set it upon startup, or while the hardware is running)
Ah awesome, it breaks here:

<dbg>r

PC   A X Y Z B SP   MAPL MAPH LAST-OP     P P-FLAGS   RGP uS IO
8100 11 22 33 00 BF BEFF 4000 3F00 00       24 00 ..E..I... ..P 11 -00 H-
<dbg>dis
---------------------------------------
#1: STRING dos_requested_filename: Venezualen casaba melon production statistics (2007-2011).txt
---------------------------------------
> kickstart.a65:192
> 182: nop
> 183: jmp nosuchtrap
> 184: nop
> 185: jmp nosuchtrap
> 186: nop
> 187: jmp nosuchtrap
> 188: nop
> 189: jmp nosuchtrap
> 190: nop
> 191: ; Traps $40-$4F (reset, page fault and other system-generated traps)
> 192: jmp reset_entry_allow_etherkick ; Trap #$40 (power on / reset)
> 193: nop
> 194: jmp page_fault   ; Trap #$41 (page fault)
> 195: nop
> 196: jmp double_restore_trap   ; Trap #$42 (double-tap RESTORE key)
> 197: nop
> 198: jmp nosuchtrap
> 199: nop
> 200: jmp nosuchtrap
> 201: nop
> 202: jmp nosuchtrap
---------------------------------------
$8100      M_nnnn:2 4C 5E 93 JMP $935E

Wow, nice to know where it all starts off with this system :)

By chance, this also my watch debug info highlighted that interesting "Venezualen casaba melon production statistics (2007-2011).txt" string as the dos_requested_filename. Something about that filename always seems to pique my curiosity. Is this some sort of cryptic easter egg? :D

Gurce

Paul Gardner-Stephen

unread,

Aug 21, 2016, 4:09:43 AM8/21/16

to Gurce Isikyildiz, C65GS Development, Ben-401

Hello,

General git collaboration etiquite is to work on your own repo or branch, and create pull requests when you have something ready to be merged.

As for the casaba melon productions statistics, glad you spotted it. It really was just a test string for the maximum length of file name that the MEGA65 will allow. No other special meaning, beyond that casaba melons are a recurring theme in our lab, due to various in-jokes, largely stemming from an incident when I was an undergraduate regarding the unexplained appearance of "NO CASABA MELONS ALLOWED IN THE LAB" signs in place of the usual "NO FOOD OR DRINK ALLOWED IN THE LAB" signs.

Paul.

--

Ben-401

unread,

Aug 30, 2016, 12:04:25 AM8/30/16

to C65GS Development

I have placed two scripts in the development branch:
https://github.com/MEGA65/mega65-core/tree/development/src/utilities
these two script allow you to:
- get or examine the contents of a sd card, and
- set or format a card to a certain specification.

I am yet to try them on mac, but work fine under linux.

I am reviewing the kickstart and dos code in the "mvfile" branch

Ben-401

unread,

Aug 30, 2016, 1:44:32 AM8/30/16

to C65GS Development

Below is the fsck info from the only known working sdcard (Pauls 2GB non-SDHC).
With an alternate card I will try and create the layout as shown below.

Boot sector contents:
System ID "MSDOS5.0"
Media byte 0xf8 (hard disk)
       512 bytes per logical sector
      4096 bytes per cluster
       568 reserved sectors
First FAT starts at byte 290816 (sector 568)
         2 FATs, 32 bit entries
   1951744 bytes per FAT (= 3812 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 4194304 (sector 8192)
    487919 data clusters (1998516224 bytes)
63 sectors/track, 255 heads
       129 hidden sectors
   3911551 sectors total
FATs differ but appear to be intact. Using first FAT.
Checking for unused clusters.
Checking free cluster summary.
Leaving filesystem unchanged.
/dev/sdc1: 128 files, 10611/487919 clusters

Ben-401

unread,

Aug 30, 2016, 11:05:16 PM8/30/16

to C65GS Development

and below is the fdisk info of Pauls 2G sdcard:

Disk /dev/sdc: 1.9 GiB, 2002780160 bytes, 3911680 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device Boot Start End Sectors Size Id Type
/dev/sdc1 129 3911679 3911551 1.9G b W95 FAT32

Ben-401

unread,

Aug 31, 2016, 8:40:11 AM8/31/16

to C65GS Development

i just commented in issue #1

I am now able to format a card, and have that card read by the KICKUP code.
format using $src/utilities/setsdformat.sh
copy ALL files on, because if it cant find a file it looks for, it behaves badly.
i have modified KICKUP, on the MVFILE branch,
currently there are heaps of debug messages,

I hope to be in a position soon to cherry-pick my major-changes and incorporate these into the dev-branch.

Ben-401

unread,

Sep 2, 2016, 2:30:22 AM9/2/16

to C65GS Development

I have uploaded my changes to the MVFILE branch
so:
git checkout github/mega65/mega65-core <or similar>
cd mega65
git checkout mvfile
./compile

while its compiling, get a SDCARD of size 1, 2, or 4G, and run the src/utilities/setsdcard.sh on it.
you need to place all six files on the card,
ANY ORDER, ALL UPPERCASE, ALL 8.3 filename
- KICKUP.M65
- BOOTLOGO.M65
- MEGA65.ROM
- CHARROM.M65
- MEGA65.D81
sixth file is RUN.BIT, where RUN can be any word but in upper case.

when the mega65 boots up, some extra messages are displayed to the screen,
turn in SW-15 to allow viewing of screen messages before GO64
and significantly more debug messages are sent to the console debugger is SW-12 is on,.

Currently there remains an issue with long filenames, and deleted entries.
Seems my 6502/MEGA assembly skills need some practice as I cannot seem to get he CMP/BNE working...

For now, it seems that I can make a new SDCARD and continue development, when the old SDCARD fails (maybe due to reusing previously used FAT entries, i dunno).

To save you compiling the architecture, I have attached the KICKUP file.

KICKUP.M65

Daniel England

unread,

Sep 2, 2016, 2:42:39 AM9/2/16

to C65GS Development

Hey, good work.

Is there any news about SDHC compatibility?

Are you changing the contents of the MEGA65.D81 file routinely? If so, what tools are you using? Is there a need for D64 Explorer to handle importing/exporting files?

Daniel.

Ben-401

unread,

Sep 2, 2016, 6:20:58 AM9/2/16

to C65GS Development

good point Daniel, the news I have is: SDHC compatibility does not work.
=> Need to use pain SD cards (ie non-SDHC)

Currently the MEGA65.D81 contains files that I am not familiar with, and include a few games etc.
NOTE: that you can use ANY D81 image and rename it to MEGA65.D81 and it will be autoloaded.

Currently I write the file.a65 (located in src/utilities) and use Ophis to compile that to a PRG. Then CMBCONVERT to pack those into a D81 image, then rename the file to MEGA65.D81 (or just mount the utilities.D81 image using SYS49152).

My intention is to have by default (on the MEGA65.D81 image that is auto-loaded), a suite of programs that can demonstrate the abilities of the MEGA65, namely how to access screen memory, the different screen resolutions, variable-width-font, how to display a logo, raster bars, networking etc etc, but then we get off topic.

LGB Gábor Lénárt

unread,

Sep 2, 2016, 12:27:43 PM9/2/16

to C65GS Development

Hi,

On Wednesday, August 31, 2016 at 2:40:11 PM UTC+2, Ben-401 wrote:

i just commented in issue #1

I am now able to format a card, and have that card read by the KICKUP code.
format using $src/utilities/setsdformat.sh

It seems this script uses /dev/sdc1 hard coded at one place (at mkfs.vfat), but a parameter at other places, forgotten to be updated from the hard coded value? ;) The other issue with this script that for example my notebook with SD card reader built in uses device node /dev/mmcblk0 for the whole card, but /dev/mmcblk0p1 for the partition! It seems an extra "p" is included in the udev naming scheme, maybe to avoid numbers to be joined. It wouldn't the case with /dev/sdb /dev/sdc etc for sure. I think the best option would be to use the partition device node name got from the fdisk part of the run, where partition is created and fdisk reports the correct device name in either case.

But in general, that's great, with looking the parameters of mkfs.vfat got, I managed to create a working disk image even with my M65 emulator :) What I've tried with mkfs.vfat didn't worked ... :( If you remember my huge image :D

Ben-401

unread,

Sep 5, 2016, 12:53:51 AM9/5/16

to C65GS Development

thanks Gabor,
I have started
https://groups.google.com/forum/#!topic/c65gs-development/D-m-VeUHWBI
for discussions related to the script development. Can you please comment there?

Ben-401

unread,

Sep 5, 2016, 9:47:53 PM9/5/16

to C65GS Development

On Tuesday, September 6, 2016 at 1:04:52 AM UTC+9:30, LGB Gábor Lénárt wrote:Hi,

About the image:

There is something interesting here with the filesystem it seems. Deft sent me an SD card image (thanks!), and that worked (with my emulator I mean, without any problem). Since you told, it's OK for you with your own created one as well, there must be with the copying files process maybe (at my side, I mean, FS creation should be OK, if it worked for you since it should be the very same result). Yes, I am aware of fragmentation, with a new image, I just copy files, and no other modification is done, so hopefully it shouldn't be fragmented at all. How exactly you copied the files? I simply mounted the partition on Linux, and copied the files (maybe I should use some mount options regarding to the FS, or better use mcopy from the mtools package), with the desired name, also caring about the uppercase stuff (though I am not sure if FAT is case sensitive, and I don't mean the OS now, but the disk FS directory entry level, especially with LFNs etc ...). But anyway, even with my image, my emulator booted in the C65 mode, and the C65 ROM itself is loaded by the kickstart, so it can't be totally wrong! The odd thing, that as far as I can tell, it works if a *given* file name is searched for, eg for example C65.ROM. But the disk chooser seems to "scan" the directory and that is the problem that it can't see the end of directory ... Also fragmentation should not apply here anyway, as the files can be loaded by kickstart (ie the C65 ROM) the problem can be seen only at read dir trap issued by the disk chooser utility (SYS49152). I haven't even deleted files, just copied news. With a "brand new" FS created first. I tried several kickup files built myself from all branches of the mega65-core github repository.

Yes, I emulate "hypervisor check points" to be shown, and FPGA-12 switch is emulated to be ON. Btw you can see how it works: http://c65gs.blogspot.hu/2016/09/mega65-emulator-can-run-kickstart-and.html

What I get (the "Hypervisor serial output:" part is printed by my emulator, the checkpoint itself is generated by the kickstart though):

Hypervisor serial output: "Checkpoint @ $8408 A:$14, X:$14, Y:$0F, Z:$00, P:$35 :trap_dos_readdir
           ".
Hypervisor serial output: "Checkpoint @ $8983 A:$10, X:$10, Y:$0F, Z:$00, P:$35 :dos_readdir <entry>                     ".
Hypervisor serial output: "Checkpoint @ $89F7 A:$3F, X:$1B, Y:$0B, Z:$00, P:$35 :next piece (8.3) =???????????           ".
Hypervisor serial output: "Checkpoint @ $8B31 A:$00, X:$1B, Y:$0B, Z:$00, P:$B4 :drce_shortname                          ".
Hypervisor serial output: "Checkpoint @ $8D00 A:$00, X:$1B, Y:$00, Z:$00, P:$37 :drd_deleted_or_invalid_entry            ".

Not counting the first line, the rests repeating. Before this point, I see that valid files are shown, D81's even shown by the chooser. I started to put extra checkpoints in the source, since I can't tell I clearly understand the source at the first glance, maybe it will help me :)

Please note, that I don't think it's the fault of your script, though quite interesting problem for me, at least for some unknown reason to me yet ...

interested to know what you would do another way.

I run the script on ubuntu, putsdcard in vista and copy 6x files, then put sdcard in fpga.

Yes, the GIVEN filename searched for MUST exist on the disk, else the boot-code searches but cant find it - I do hope to fix this up.

As for filenames, the boot-code seems to complain on LONG-filenames and LOWER-case, so I make all files UPPER and SHORT=8.3

Please use the kickup file four-posts-above, and let me know if that works better?
this kickup file is generated from the MVFILE branch which I am developing

I will post the boot-log next

Ben-401

unread,

Sep 5, 2016, 10:02:36 PM9/5/16

to C65GS Development

Here is my boot-log,
I have cut repetitive lines, and put some narration through it
Yes, we need to reduce the noise in these "Checkpoint" messages

PC A X Y Z B SP MAPL MAPH LAST-OP P P-FLAGS RGP uS IO

9ECA 2E C1 E5 3F BF BEFB C1C0 3F00 71 09    24 00 ..E..I... ... 50 -C9 H-
.

MEGA65 Serial Monitor
build mvfile,06f4f0b+DIRTY,0826-1849
--------------------------------
See source code for help.

@
@ note above the old bit-file being used,
@ and has embeded an old version of KICKUP
@

.0, Y:$10, Z:$00, P:$37 :reset_machine_state
Checkpoint @ $9348 A:$0C, X:$00, Y:$10, Z:$00, P:$35 :reset_machine_state
Checkpoint @ $8983 A:$00, X:$00, Y:$00, Z:$01, P:$37 :dos_readdir <entry>
Checkpoint @ $89F7 A:$20, X:$0B, Y:$0B, Z:$00, P:$35 :next piece (8.3) =LOUD
Checkpoint @ $8B31 A:$08, X:$0B, Y:$0B, Z:$00, P:$B4 :drce_shortname
Checkpoint @ $8B50 A:$4C, X:$0B, Y:$00, Z:$00, P:$34 :drce_shortname <2>
Checkpoint @ $8B74 A:$20, X:$0B, Y:$0B, Z:$00, P:$37 :drce5
Checkpoint @ $8BC0 A:$20, X:$06, Y:$09, Z:$01, P:$37 :drce_copied_extension
Checkpoint @ $8BE2 A:$00, X:$06, Y:$09, Z:$01, P:$37
:drce_already_have_long_name
Checkpoint @ $8C32 A:$08, X:$04, Y:$0B, Z:$01, P:$35 :drce_fl <1>
Checkpoint @ $8C65 A:$20, X:$04, Y:$00, Z:$01, P:$35 :drce_noteof
Checkpoint @ $8C88 A:$4C, X:$04, Y:$00, Z:$01, P:$35 :drce_noteof <success>
Checkpoint @ $8CBE A:$4C, X:$04, Y:$00, Z:$01, P:$34 :LFN(9): LOUD.
????????????????????????
Checkpoint @ $8983 A:$06, X:$04, Y:$00, Z:$01, P:$B4 :dos_readdir <entry>
Checkpoint @ $89F7 A:$35, X:$0B, Y:$0B, Z:$00, P:$35 :next piece (8.3)
=KICKUP M65
Checkpoint @ $8B31 A:$20, X:$0B, Y:$0B, Z:$00, P:$35 :drce_shortname
Checkpoint @ $8B50 A:$4B, X:$0B, Y:$00, Z:$00, P:$34 :drce_shortname <2>
Checkpoint @ $8B74 A:$35, X:$0B, Y:$0B, Z:$00, P:$37 :drce5
Checkpoint @ $8BC0 A:$35, X:$0A, Y:$0B, Z:$03, P:$37 :drce_copied_extension
Checkpoint @ $8BE2 A:$00, X:$0A, Y:$0B, Z:$03, P:$37
:drce_already_have_long_name
Checkpoint @ $8C32 A:$20, X:$04, Y:$0B, Z:$03, P:$35 :drce_fl <1>
Checkpoint @ $8C65 A:$40, X:$04, Y:$00, Z:$03, P:$35 :drce_noteof
Checkpoint @ $8C88 A:$4B, X:$04, Y:$00, Z:$03, P:$35 :drce_noteof <success>
Checkpoint @ $8CBE A:$4B, X:$04, Y:$00, Z:$03, P:$34 :LFN(9):
KICKUP.M65????????????????????
Checkpoint @ $8983 A:$0A, X:$04, Y:$00, Z:$03, P:$B4 :dos_readdir <entry>
Checkpoint @ $89F7 A:$4D, X:$0B, Y:$0B, Z:$00, P:$35 :next piece (8.3)
=MEGA65 ROM
Checkpoint @ $8B31 A:$20, X:$0B, Y:$0B, Z:$00, P:$35 :drce_shortname
Checkpoint @ $8B50 A:$4D, X:$0B, Y:$00, Z:$00, P:$34 :drce_shortname <2>
Checkpoint @ $8B74 A:$4D, X:$0B, Y:$0B, Z:$00, P:$37 :drce5
Checkpoint @ $8BC0 A:$4D, X:$0A, Y:$0B, Z:$03, P:$37 :drce_copied_extension
Checkpoint @ $8BE2 A:$00, X:$0A, Y:$0B, Z:$03, P:$37
:drce_already_have_long_name
Checkpoint @ $8C32 A:$20, X:$04, Y:$0B, Z:$03, P:$35 :drce_fl <1>
Checkpoint @ $8C65 A:$60, X:$04, Y:$00, Z:$03, P:$35 :drce_noteof
Checkpoint @ $8C88 A:$4D, X:$04, Y:$00, Z:$03, P:$35 :drce_noteof <success>
Checkpoint @ $8CBE A:$4D, X:$04, Y:$00, Z:$03, P:$34 :LFN(9):
MEGA65.ROM????????????????????
Checkpoint @ $8983 A:$0A, X:$04, Y:$00, Z:$03, P:$B4 :dos_readdir <entry>
Checkpoint @ $89F7 A:$54, X:$0B, Y:$0B, Z:$00, P:$35 :next piece (8.3)
=BIT4F0B BIT
Checkpoint @ $8B31 A:$20, X:$0B, Y:$0B, Z:$00, P:$35 :drce_shortname
Checkpoint @ $8B50 A:$42, X:$0B, Y:$00, Z:$00, P:$34 :drce_shortname <2>
Checkpoint @ $8B74 A:$54, X:$0B, Y:$0B, Z:$00, P:$37 :drce5
Checkpoint @ $8BC0 A:$54, X:$0B, Y:$0B, Z:$03, P:$37 :drce_copied_extension
Checkpoint @ $8BE2 A:$00, X:$0B, Y:$0B, Z:$03, P:$37
:drce_already_have_long_name
Checkpoint @ $8C32 A:$20, X:$04, Y:$0B, Z:$03, P:$35 :drce_fl <1>
Checkpoint @ $8C65 A:$80, X:$04, Y:$00, Z:$03, P:$F5 :drce_noteof
Checkpoint @ $8C88 A:$42, X:$04, Y:$00, Z:$03, P:$35 :drce_noteof <success>
Checkpoint @ $8CBE A:$42, X:$04, Y:$00, Z:$03, P:$34 :LFN(9):
BIT4F0B.BIT???????????????????
Checkpoint @ $8983 A:$0B, X:$04, Y:$00, Z:$03, P:$B4 :dos_readdir <entry>
Checkpoint @ $89F7 A:$35, X:$0B, Y:$0B, Z:$00, P:$35 :next piece (8.3)
=BOOTLOGOM65
Checkpoint @ $8B31 A:$20, X:$0B, Y:$0B, Z:$00, P:$35 :drce_shortname
Checkpoint @ $8B50 A:$42, X:$0B, Y:$00, Z:$00, P:$34 :drce_shortname <2>
Checkpoint @ $8B74 A:$35, X:$0B, Y:$0B, Z:$00, P:$37 :drce5
Checkpoint @ $8BC0 A:$35, X:$0C, Y:$0B, Z:$03, P:$37 :drce_copied_extension
Checkpoint @ $8BE2 A:$00, X:$0C, Y:$0B, Z:$03, P:$37
:drce_already_have_long_name
Checkpoint @ $8C32 A:$20, X:$04, Y:$0B, Z:$03, P:$35 :drce_fl <1>
Checkpoint @ $8C65 A:$A0, X:$04, Y:$00, Z:$03, P:$B5 :drce_noteof
Checkpoint @ $8C88 A:$42, X:$04, Y:$00, Z:$03, P:$35 :drce_noteof <success>
Checkpoint @ $8CBE A:$42, X:$04, Y:$00, Z:$03, P:$34 :LFN(9):
BOOTLOGO.M65??????????????????
Checkpoint @ $8983 A:$00, X:$00, Y:$00, Z:$00, P:$37 :dos_readdir <entry>
Checkpoint @ $89F7 A:$20, X:$0B, Y:$0B, Z:$00, P:$35 :next piece (8.3) =LOUD
Checkpoint @ $8B31 A:$08, X:$0B, Y:$0B, Z:$00, P:$B4 :drce_shortname
Checkpoint @ $8B50 A:$4C, X:$0B, Y:$00, Z:$00, P:$34 :drce_shortname <2>
Checkpoint @ $8B74 A:$20, X:$0B, Y:$0B, Z:$00, P:$37 :drce5
Checkpoint @ $8BC0 A:$20, X:$06, Y:$09, Z:$01, P:$37 :drce_copied_extension
Checkpoint @ $8BE2 A:$00, X:$06, Y:$09, Z:$01, P:$37
:drce_already_have_long_name
Checkpoint @ $8C32 A:$08, X:$04, Y:$0B, Z:$01, P:$35 :drce_fl <1>
Checkpoint @ $8C65 A:$20, X:$04, Y:$00, Z:$01, P:$35 :drce_noteof
Checkpoint @ $8C88 A:$4C, X:$04, Y:$00, Z:$01, P:$35 :drce_noteof <success>
Checkpoint @ $8CBE A:$4C, X:$04, Y:$00, Z:$01, P:$34 :LFN(9): LOUD.
????????????????????????
Checkpoint @ $8983 A:$06, X:$04, Y:$00, Z:$01, P:$B4 :dos_readdir <entry>
Checkpoint @ $89F7 A:$35, X:$0B, Y:$0B, Z:$00, P:$35 :next piece (8.3)
=KICKUP M65
Checkpoint @ $8B31 A:$20, X:$0B, Y:$0B, Z:$00, P:$35 :drce_shortname
Checkpoint @ $8B50 A:$4B, X:$0B, Y:$00, Z:$00, P:$34 :drce_shortname <2>
Checkpoint @ $8B74 A:$35, X:$0B, Y:$0B, Z:$00, P:$37 :drce5
Checkpoint @ $8BC0 A:$35, X:$0A, Y:$0B, Z:$03, P:$37 :drce_copied_extension
Checkpoint @ $8BE2 A:$00, X:$0A, Y:$0B, Z:$03, P:$37
:drce_already_have_long_name
Checkpoint @ $8C32 A:$20, X:$04, Y:$0B, Z:$03, P:$35 :drce_fl <1>
Checkpoint @ $8C65 A:$40, X:$04, Y:$00, Z:$03, P:$35 :drce_noteof
Checkpoint @ $8C88 A:$4B, X:$04, Y:$00, Z:$03, P:$35 :drce_noteof <success>
Checkpoint @ $8CBE A:$4B, X:$04, Y:$00, Z:$03, P:$34 :LFN(9):
KICKUP.M65????????????????????

@
@ now about to use the new version of KICKUP
@

Checkpoint @ $9664 A:$0C, X:$00, Y:$10, Z:$53, P:$37 :reset_machine_state
Checkpoint @ $967C A:$0C, X:$00, Y:$10, Z:$53, P:$35 :reset_machine_state
Checkpoint @ $9C05 A:$00, X:$00, Y:$15, Z:$53, P:$34 :Resetting SDCARD
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$53, P:$34
:sd_read(ing)sector: $d681=00000000.
Checkpoint @ $86E2 A:$00, X:$30, Y:$30, Z:$53, P:$37 :Reading MBR @
0x00000000
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$53, P:$34
:sd_read(ing)sector: $d681=00000000.
Checkpoint @ $860F A:$AA, X:$30, Y:$30, Z:$53, P:$37 :Found $55AA at
$1FE on MBR
Checkpoint @ $8638 A:$DF, X:$30, Y:$30, Z:$53, P:$B5 :Checking Partition #1
Checkpoint @ $8725 A:$0C, X:$30, Y:$04, Z:$53, P:$37 :Partn has
fat32_lba (type=0x0c)
Checkpoint @ $8844 A:$00, X:$08, Y:$10, Z:$53, P:$37 :OK:
dos_disk_openpartition:
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$53, P:$34
:sd_read(ing)sector: $d681=00100000.
Checkpoint @ $88A0 A:$AA, X:$30, Y:$30, Z:$53, P:$37 :Partn has $55AA GOOD
Checkpoint @ $89FF A:$0F, X:$FF, Y:$08, Z:$01, P:$34 :FAT32 partition
data copied to
Checkpoint @ $87D7 A:$31, X:$31, Y:$30, Z:$01, P:$34 :Part#1 NOT set to
the default_disk
Checkpoint @ $86E2 A:$00, X:$31, Y:$30, Z:$01, P:$37 :Reading MBR @
0x00000000
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$01, P:$34
:sd_read(ing)sector: $d681=00000000.
Checkpoint @ $8660 A:$CE, X:$30, Y:$30, Z:$01, P:$B5 :Checking Partition #2
Checkpoint @ $8800 A:$01, X:$30, Y:$04, Z:$01, P:$34 :Partition not
interesting
Checkpoint @ $86E2 A:$00, X:$30, Y:$04, Z:$01, P:$37 :Reading MBR @
0x00000000
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$01, P:$34
:sd_read(ing)sector: $d681=00000000.
Checkpoint @ $8688 A:$DE, X:$30, Y:$30, Z:$01, P:$B5 :Checking Partition #3
Checkpoint @ $8800 A:$01, X:$30, Y:$04, Z:$01, P:$34 :Partition not
interesting
Checkpoint @ $86E2 A:$00, X:$30, Y:$04, Z:$01, P:$37 :Reading MBR @
0x00000000
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$01, P:$34
:sd_read(ing)sector: $d681=00000000.
Checkpoint @ $86B0 A:$EE, X:$30, Y:$30, Z:$01, P:$B5 :Checking Partition #4
Checkpoint @ $8800 A:$01, X:$30, Y:$04, Z:$01, P:$34 :Partition not
interesting

@
@ will now search for the bootlogo, parsing dir until it finds it
@

Checkpoint @ $987E A:$00, X:$01, Y:$0C, Z:$00, P:$37 : try-loading BOOTLOGO
Checkpoint @ $926E A:$30, X:$00, Y:$2C, Z:$00, P:$34
:dos_print_current_cluster
Checkpoint @ $8BB1 A:$30, X:$30, Y:$30, Z:$00, P:$34
:dos_readdir[0000]======================
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $8C5B A:$38, X:$0B, Y:$30, Z:$00, P:$34 :BGOK (8.3)+ATTRIB
=LOUD        08
Checkpoint @ $8CBB A:$00, X:$0B, Y:$08, Z:$00, P:$37 : is Volume ID, so
skip this record
Checkpoint @ $8BB1 A:$30, X:$30, Y:$30, Z:$00, P:$34
:dos_readdir[0020]======================
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $8C5B A:$30, X:$0B, Y:$32, Z:$00, P:$34 :BGOK (8.3)+ATTRIB
=KICKUP M65 20
Checkpoint @ $8E0B A:$00, X:$0B, Y:$20, Z:$00, P:$37 :BGOK drce: not
longname
Checkpoint @ $8EB9 A:$20, X:$04, Y:$0B, Z:$03, P:$35 :BGOK drce_fl
populated fields
Checkpoint @ $8F03 A:$40, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<1/3>
Checkpoint @ $8F27 A:$0A, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<2/3>
Checkpoint @ $8F4E A:$4B, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<3/3>
Checkpoint @ $8F8B A:$4B, X:$41, Y:$30, Z:$03, P:$34 :LFN(0A):
KICKUP.M65????????????????????
Checkpoint @ $8BB1 A:$30, X:$30, Y:$30, Z:$03, P:$34
:dos_readdir[0040]======================
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $8C5B A:$30, X:$0B, Y:$32, Z:$00, P:$34 :BGOK (8.3)+ATTRIB
=MEGA65 ROM 20
Checkpoint @ $8E0B A:$00, X:$0B, Y:$20, Z:$00, P:$37 :BGOK drce: not
longname
Checkpoint @ $8EB9 A:$20, X:$04, Y:$0B, Z:$03, P:$35 :BGOK drce_fl
populated fields
Checkpoint @ $8F03 A:$60, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<1/3>
Checkpoint @ $8F27 A:$0A, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<2/3>
Checkpoint @ $8F4E A:$4D, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<3/3>
Checkpoint @ $8F8B A:$4D, X:$41, Y:$30, Z:$03, P:$34 :LFN(0A):
MEGA65.ROM????????????????????
Checkpoint @ $8BB1 A:$30, X:$30, Y:$30, Z:$03, P:$34
:dos_readdir[0060]======================
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $8C5B A:$30, X:$0B, Y:$32, Z:$00, P:$34 :BGOK (8.3)+ATTRIB
=BIT4F0B BIT 20
Checkpoint @ $8E0B A:$00, X:$0B, Y:$20, Z:$00, P:$37 :BGOK drce: not
longname
Checkpoint @ $8EB9 A:$20, X:$04, Y:$0B, Z:$03, P:$35 :BGOK drce_fl
populated fields
Checkpoint @ $8F03 A:$80, X:$04, Y:$00, Z:$03, P:$F5 :BGOK drce_not_eof
<1/3>
Checkpoint @ $8F27 A:$0B, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<2/3>
Checkpoint @ $8F4E A:$42, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<3/3>
Checkpoint @ $8F8B A:$42, X:$42, Y:$30, Z:$03, P:$34 :LFN(0B):
BIT4F0B.BIT???????????????????
Checkpoint @ $8BB1 A:$30, X:$30, Y:$30, Z:$03, P:$34
:dos_readdir[0080]======================
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $8C5B A:$30, X:$0B, Y:$32, Z:$00, P:$34 :BGOK (8.3)+ATTRIB
=BOOTLOGOM65 20
Checkpoint @ $8E0B A:$00, X:$0B, Y:$20, Z:$00, P:$37 :BGOK drce: not
longname
Checkpoint @ $8EB9 A:$20, X:$04, Y:$0B, Z:$03, P:$35 :BGOK drce_fl
populated fields
Checkpoint @ $8F03 A:$A0, X:$04, Y:$00, Z:$03, P:$B5 :BGOK drce_not_eof
<1/3>
Checkpoint @ $8F27 A:$0C, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<2/3>
Checkpoint @ $8F4E A:$42, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<3/3>
Checkpoint @ $8F8B A:$42, X:$43, Y:$30, Z:$03, P:$34 :LFN(0C):
BOOTLOGO.M65??????????????????

@
@ found it, now reads it
@

Checkpoint @ $8FFE A:$4F, X:$00, Y:$30, Z:$03, P:$37 :Found the file...
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=0060C800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=0060CA00.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=0060CC00.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=0060CE00.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=0060D000.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=0060D200.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=0060D400.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=0060D600.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00147E00.
Checkpoint @ $91C5 A:$0F, X:$3C, Y:$0A, Z:$04, P:$37 :WARN: PRINTHEX in
dfanc_check
Checkpoint @ $98CC A:$00, X:$00, Y:$06, Z:$00, P:$37 : fallthrough
loading BOOTLOGO

@
@ now searching for the MEGA65.D81
@

Checkpoint @ $99B3 A:$00, X:$00, Y:$19, Z:$00, P:$37 : Here we are
POST-KICKUP
Checkpoint @ $99E3 A:$00, X:$EB, Y:$0A, Z:$00, P:$37 : try-mounting
MEGA65.D81
Checkpoint @ $8BB1 A:$30, X:$30, Y:$30, Z:$00, P:$34
:dos_readdir[0000]======================
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $8C5B A:$38, X:$0B, Y:$30, Z:$00, P:$34 :BGOK (8.3)+ATTRIB
=LOUD        08
Checkpoint @ $8CBB A:$00, X:$0B, Y:$08, Z:$00, P:$37 : is Volume ID, so
skip this record
Checkpoint @ $8BB1 A:$30, X:$30, Y:$30, Z:$00, P:$34
:dos_readdir[0020]======================
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $8C5B A:$30, X:$0B, Y:$32, Z:$00, P:$34 :BGOK (8.3)+ATTRIB
=KICKUP M65 20
Checkpoint @ $8E0B A:$00, X:$0B, Y:$20, Z:$00, P:$37 :BGOK drce: not
longname
Checkpoint @ $8EB9 A:$20, X:$04, Y:$0B, Z:$03, P:$35 :BGOK drce_fl
populated fields
Checkpoint @ $8F03 A:$40, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<1/3>
Checkpoint @ $8F27 A:$0A, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<2/3>
Checkpoint @ $8F4E A:$4B, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<3/3>
Checkpoint @ $8F8B A:$4B, X:$41, Y:$30, Z:$03, P:$34 :LFN(0A):
KICKUP.M65????????????????????
Checkpoint @ $8BB1 A:$30, X:$30, Y:$30, Z:$03, P:$34
:dos_readdir[0040]======================
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $8C5B A:$30, X:$0B, Y:$32, Z:$00, P:$34 :BGOK (8.3)+ATTRIB
=MEGA65 ROM 20
Checkpoint @ $8E0B A:$00, X:$0B, Y:$20, Z:$00, P:$37 :BGOK drce: not
longname
Checkpoint @ $8EB9 A:$20, X:$04, Y:$0B, Z:$03, P:$35 :BGOK drce_fl
populated fields
Checkpoint @ $8F03 A:$60, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<1/3>
Checkpoint @ $8F27 A:$0A, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<2/3>
Checkpoint @ $8F4E A:$4D, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<3/3>
Checkpoint @ $8F8B A:$4D, X:$41, Y:$30, Z:$03, P:$34 :LFN(0A):
MEGA65.ROM????????????????????
Checkpoint @ $8BB1 A:$30, X:$30, Y:$30, Z:$03, P:$34
:dos_readdir[0060]======================
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $8C5B A:$30, X:$0B, Y:$32, Z:$00, P:$34 :BGOK (8.3)+ATTRIB
=BIT4F0B BIT 20
Checkpoint @ $8E0B A:$00, X:$0B, Y:$20, Z:$00, P:$37 :BGOK drce: not
longname
Checkpoint @ $8EB9 A:$20, X:$04, Y:$0B, Z:$03, P:$35 :BGOK drce_fl
populated fields
Checkpoint @ $8F03 A:$80, X:$04, Y:$00, Z:$03, P:$F5 :BGOK drce_not_eof
<1/3>
Checkpoint @ $8F27 A:$0B, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<2/3>
Checkpoint @ $8F4E A:$42, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<3/3>
Checkpoint @ $8F8B A:$42, X:$42, Y:$30, Z:$03, P:$34 :LFN(0B):
BIT4F0B.BIT???????????????????
Checkpoint @ $8BB1 A:$30, X:$30, Y:$30, Z:$03, P:$34
:dos_readdir[0080]======================
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $8C5B A:$30, X:$0B, Y:$32, Z:$00, P:$34 :BGOK (8.3)+ATTRIB
=BOOTLOGOM65 20
Checkpoint @ $8E0B A:$00, X:$0B, Y:$20, Z:$00, P:$37 :BGOK drce: not
longname
Checkpoint @ $8EB9 A:$20, X:$04, Y:$0B, Z:$03, P:$35 :BGOK drce_fl
populated fields
Checkpoint @ $8F03 A:$A0, X:$04, Y:$00, Z:$03, P:$B5 :BGOK drce_not_eof
<1/3>
Checkpoint @ $8F27 A:$0C, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<2/3>
Checkpoint @ $8F4E A:$42, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<3/3>
Checkpoint @ $8F8B A:$42, X:$43, Y:$30, Z:$03, P:$34 :LFN(0C):
BOOTLOGO.M65??????????????????
Checkpoint @ $8BB1 A:$30, X:$30, Y:$30, Z:$03, P:$34
:dos_readdir[00A0]======================
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $8C5B A:$30, X:$0B, Y:$32, Z:$00, P:$34 :BGOK (8.3)+ATTRIB
=CHARROM M65 20
Checkpoint @ $8E0B A:$00, X:$0B, Y:$20, Z:$00, P:$37 :BGOK drce: not
longname
Checkpoint @ $8EB9 A:$20, X:$04, Y:$0B, Z:$03, P:$35 :BGOK drce_fl
populated fields
Checkpoint @ $8F03 A:$C0, X:$04, Y:$00, Z:$03, P:$B5 :BGOK drce_not_eof
<1/3>
Checkpoint @ $8F27 A:$0B, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<2/3>
Checkpoint @ $8F4E A:$43, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<3/3>
Checkpoint @ $8F8B A:$43, X:$42, Y:$30, Z:$03, P:$34 :LFN(0B):
CHARROM.M65???????????????????
Checkpoint @ $8BB1 A:$30, X:$30, Y:$30, Z:$03, P:$34
:dos_readdir[00C0]======================
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $8C5B A:$30, X:$0B, Y:$32, Z:$00, P:$34 :BGOK (8.3)+ATTRIB
=MEGA65 D81 20
Checkpoint @ $8E0B A:$00, X:$0B, Y:$20, Z:$00, P:$37 :BGOK drce: not
longname
Checkpoint @ $8EB9 A:$20, X:$04, Y:$0B, Z:$03, P:$35 :BGOK drce_fl
populated fields
Checkpoint @ $8F03 A:$E0, X:$04, Y:$00, Z:$03, P:$B5 :BGOK drce_not_eof
<1/3>
Checkpoint @ $8F27 A:$0A, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<2/3>
Checkpoint @ $8F4E A:$4D, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<3/3>
Checkpoint @ $8F8B A:$4D, X:$41, Y:$30, Z:$03, P:$34 :LFN(0A):
MEGA65.D81????????????????????
Checkpoint @ $8FFE A:$45, X:$00, Y:$30, Z:$03, P:$37 :Found the file...

@
@ found the D81, now... parses dir again and checks for fragmentation I think
@

Checkpoint @ $930D A:$FF, X:$00, Y:$30, Z:$03, P:$B5 :dos_d81attach
<checking>
Checkpoint @ $8BB1 A:$30, X:$30, Y:$30, Z:$03, P:$34
:dos_readdir[0000]======================
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $8C5B A:$38, X:$0B, Y:$30, Z:$00, P:$34 :BGOK (8.3)+ATTRIB
=LOUD        08
Checkpoint @ $8CBB A:$00, X:$0B, Y:$08, Z:$00, P:$37 : is Volume ID, so
skip this record
Checkpoint @ $8BB1 A:$30, X:$30, Y:$30, Z:$00, P:$34
:dos_readdir[0020]======================
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $8C5B A:$30, X:$0B, Y:$32, Z:$00, P:$34 :BGOK (8.3)+ATTRIB
=KICKUP M65 20
Checkpoint @ $8E0B A:$00, X:$0B, Y:$20, Z:$00, P:$37 :BGOK drce: not
longname
Checkpoint @ $8EB9 A:$20, X:$04, Y:$0B, Z:$03, P:$35 :BGOK drce_fl
populated fields
Checkpoint @ $8F03 A:$40, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<1/3>
Checkpoint @ $8F27 A:$0A, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<2/3>
Checkpoint @ $8F4E A:$4B, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<3/3>
Checkpoint @ $8F8B A:$4B, X:$41, Y:$30, Z:$03, P:$34 :LFN(0A):
KICKUP.M65????????????????????
Checkpoint @ $8BB1 A:$30, X:$30, Y:$30, Z:$03, P:$34
:dos_readdir[0040]======================
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $8C5B A:$30, X:$0B, Y:$32, Z:$00, P:$34 :BGOK (8.3)+ATTRIB
=MEGA65 ROM 20
Checkpoint @ $8E0B A:$00, X:$0B, Y:$20, Z:$00, P:$37 :BGOK drce: not
longname
Checkpoint @ $8EB9 A:$20, X:$04, Y:$0B, Z:$03, P:$35 :BGOK drce_fl
populated fields
Checkpoint @ $8F03 A:$60, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<1/3>
Checkpoint @ $8F27 A:$0A, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<2/3>
Checkpoint @ $8F4E A:$4D, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<3/3>
Checkpoint @ $8F8B A:$4D, X:$41, Y:$30, Z:$03, P:$34 :LFN(0A):
MEGA65.ROM????????????????????
Checkpoint @ $8BB1 A:$30, X:$30, Y:$30, Z:$03, P:$34
:dos_readdir[0060]======================
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $8C5B A:$30, X:$0B, Y:$32, Z:$00, P:$34 :BGOK (8.3)+ATTRIB
=BIT4F0B BIT 20
Checkpoint @ $8E0B A:$00, X:$0B, Y:$20, Z:$00, P:$37 :BGOK drce: not
longname
Checkpoint @ $8EB9 A:$20, X:$04, Y:$0B, Z:$03, P:$35 :BGOK drce_fl
populated fields
Checkpoint @ $8F03 A:$80, X:$04, Y:$00, Z:$03, P:$F5 :BGOK drce_not_eof
<1/3>
Checkpoint @ $8F27 A:$0B, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<2/3>
Checkpoint @ $8F4E A:$42, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<3/3>
Checkpoint @ $8F8B A:$42, X:$42, Y:$30, Z:$03, P:$34 :LFN(0B):
BIT4F0B.BIT???????????????????
Checkpoint @ $8BB1 A:$30, X:$30, Y:$30, Z:$03, P:$34
:dos_readdir[0080]======================
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $8C5B A:$30, X:$0B, Y:$32, Z:$00, P:$34 :BGOK (8.3)+ATTRIB
=BOOTLOGOM65 20
Checkpoint @ $8E0B A:$00, X:$0B, Y:$20, Z:$00, P:$37 :BGOK drce: not
longname
Checkpoint @ $8EB9 A:$20, X:$04, Y:$0B, Z:$03, P:$35 :BGOK drce_fl
populated fields
Checkpoint @ $8F03 A:$A0, X:$04, Y:$00, Z:$03, P:$B5 :BGOK drce_not_eof
<1/3>
Checkpoint @ $8F27 A:$0C, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<2/3>
Checkpoint @ $8F4E A:$42, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<3/3>
Checkpoint @ $8F8B A:$42, X:$43, Y:$30, Z:$03, P:$34 :LFN(0C):
BOOTLOGO.M65??????????????????
Checkpoint @ $8BB1 A:$30, X:$30, Y:$30, Z:$03, P:$34
:dos_readdir[00A0]======================
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $8C5B A:$30, X:$0B, Y:$32, Z:$00, P:$34 :BGOK (8.3)+ATTRIB
=CHARROM M65 20
Checkpoint @ $8E0B A:$00, X:$0B, Y:$20, Z:$00, P:$37 :BGOK drce: not
longname
Checkpoint @ $8EB9 A:$20, X:$04, Y:$0B, Z:$03, P:$35 :BGOK drce_fl
populated fields
Checkpoint @ $8F03 A:$C0, X:$04, Y:$00, Z:$03, P:$B5 :BGOK drce_not_eof
<1/3>
Checkpoint @ $8F27 A:$0B, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<2/3>
Checkpoint @ $8F4E A:$43, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<3/3>
Checkpoint @ $8F8B A:$43, X:$42, Y:$30, Z:$03, P:$34 :LFN(0B):
CHARROM.M65???????????????????
Checkpoint @ $8BB1 A:$30, X:$30, Y:$30, Z:$03, P:$34
:dos_readdir[00C0]======================
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $8C5B A:$30, X:$0B, Y:$32, Z:$00, P:$34 :BGOK (8.3)+ATTRIB
=MEGA65 D81 20
Checkpoint @ $8E0B A:$00, X:$0B, Y:$20, Z:$00, P:$37 :BGOK drce: not
longname
Checkpoint @ $8EB9 A:$20, X:$04, Y:$0B, Z:$03, P:$35 :BGOK drce_fl
populated fields
Checkpoint @ $8F03 A:$E0, X:$04, Y:$00, Z:$03, P:$B5 :BGOK drce_not_eof
<1/3>
Checkpoint @ $8F27 A:$0A, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<2/3>
Checkpoint @ $8F4E A:$4D, X:$04, Y:$00, Z:$03, P:$35 :BGOK drce_not_eof
<3/3>
Checkpoint @ $8F8B A:$4D, X:$41, Y:$30, Z:$03, P:$34 :LFN(0A):
MEGA65.D81????????????????????
Checkpoint @ $8FFE A:$45, X:$00, Y:$30, Z:$03, P:$37 :Found the file...
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$01, P:$34
:sd_read(ing)sector: $d681=00148400.
Checkpoint @ $91C5 A:$00, X:$88, Y:$1A, Z:$04, P:$37 :WARN: PRINTHEX in
dfanc_check
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00148400.
Checkpoint @ $91C5 A:$00, X:$8C, Y:$1A, Z:$04, P:$37 :WARN: PRINTHEX in
dfanc_check
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00148400.
Checkpoint @ $91C5 A:$00, X:$90, Y:$1A, Z:$04, P:$37 :WARN: PRINTHEX in
dfanc_check
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00148400.
Checkpoint @ $91C5 A:$00, X:$94, Y:$1A, Z:$04, P:$37 :WARN: PRINTHEX in
dfanc_check
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00148400.
Checkpoint @ $91C5 A:$00, X:$98, Y:$1A, Z:$04, P:$37 :WARN: PRINTHEX in
dfanc_check

@
@ deleted 10 pages of the same thing
@

Checkpoint @ $91C5 A:$00, X:$54, Y:$1A, Z:$04, P:$37 :WARN: PRINTHEX in
dfanc_check
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00148800.
Checkpoint @ $91C5 A:$00, X:$58, Y:$1A, Z:$04, P:$37 :WARN: PRINTHEX in
dfanc_check
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00148800.
Checkpoint @ $91C5 A:$00, X:$5C, Y:$1A, Z:$04, P:$37 :WARN: PRINTHEX in
dfanc_check
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00148800.
Checkpoint @ $91C5 A:$00, X:$60, Y:$1A, Z:$04, P:$37 :WARN: PRINTHEX in
dfanc_check
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00148800.
Checkpoint @ $91C5 A:$00, X:$64, Y:$1A, Z:$04, P:$37 :WARN: PRINTHEX in
dfanc_check
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00148800.
Checkpoint @ $91C5 A:$00, X:$68, Y:$1A, Z:$04, P:$37 :WARN: PRINTHEX in
dfanc_check
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00148800.
Checkpoint @ $91C5 A:$00, X:$6C, Y:$1A, Z:$04, P:$37 :WARN: PRINTHEX in
dfanc_check
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00148800.
Checkpoint @ $91C5 A:$00, X:$70, Y:$1A, Z:$04, P:$37 :WARN: PRINTHEX in
dfanc_check
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00148800.
Checkpoint @ $91C5 A:$00, X:$74, Y:$1A, Z:$04, P:$37 :WARN: PRINTHEX in
dfanc_check
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00148800.
Checkpoint @ $91C5 A:$00, X:$78, Y:$1A, Z:$04, P:$37 :WARN: PRINTHEX in
dfanc_check
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00148800.
Checkpoint @ $91C5 A:$00, X:$7C, Y:$1A, Z:$04, P:$37 :WARN: PRINTHEX in
dfanc_check
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00148800.
Checkpoint @ $91C5 A:$00, X:$80, Y:$1A, Z:$04, P:$37 :WARN: PRINTHEX in
dfanc_check
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00148800.
Checkpoint @ $91C5 A:$00, X:$84, Y:$1A, Z:$04, P:$37 :WARN: PRINTHEX in
dfanc_check
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00148800.
Checkpoint @ $91C5 A:$00, X:$88, Y:$1A, Z:$04, P:$37 :WARN: PRINTHEX in
dfanc_check
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00148800.
Checkpoint @ $91C5 A:$00, X:$8C, Y:$1A, Z:$04, P:$37 :WARN: PRINTHEX in
dfanc_check
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00148800.
Checkpoint @ $91C5 A:$00, X:$90, Y:$1A, Z:$04, P:$37 :WARN: PRINTHEX in
dfanc_check
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00148800.
Checkpoint @ $91C5 A:$00, X:$94, Y:$1A, Z:$04, P:$37 :WARN: PRINTHEX in
dfanc_check
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00148800.
Checkpoint @ $91C5 A:$00, X:$98, Y:$1A, Z:$04, P:$37 :WARN: PRINTHEX in
dfanc_check
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00148800.
Checkpoint @ $91C5 A:$00, X:$9C, Y:$1A, Z:$04, P:$37 :WARN: PRINTHEX in
dfanc_check
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00148800.
Checkpoint @ $91C5 A:$00, X:$A0, Y:$1A, Z:$04, P:$37 :WARN: PRINTHEX in
dfanc_check
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00148800.
Checkpoint @ $91C5 A:$0F, X:$A4, Y:$1A, Z:$04, P:$37 :WARN: PRINTHEX in
dfanc_check
Checkpoint @ $93C4 A:$00, X:$00, Y:$16, Z:$00, P:$36 :dos_d81attach
<measured end of image>
Checkpoint @ $942A A:$03, X:$FF, Y:$04, Z:$00, P:$34 :dos_d81attach
<success>
Checkpoint @ $9A17 A:$00, X:$00, Y:$1F, Z:$00, P:$37 : mounted MEGA65.D81

@
@ now search for charrom
@

Checkpoint @ $9A73 A:$00, X:$00, Y:$1F, Z:$3F, P:$35 : try-loading CHAR-ROM
Checkpoint @ $926E A:$31, X:$01, Y:$2C, Z:$61, P:$34
:dos_print_current_cluster
Checkpoint @ $8BB1 A:$30, X:$30, Y:$30, Z:$61, P:$34
:dos_readdir[0000]======================
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $8C5B A:$38, X:$1B, Y:$30, Z:$00, P:$34 :BGOK (8.3)+ATTRIB
=LOUD        08
Checkpoint @ $8CBB A:$00, X:$1B, Y:$08, Z:$00, P:$37 : is Volume ID, so
skip this record
Checkpoint @ $8BB1 A:$30, X:$30, Y:$30, Z:$00, P:$34
:dos_readdir[0020]======================
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $8C5B A:$30, X:$1B, Y:$32, Z:$00, P:$34 :BGOK (8.3)+ATTRIB
=KICKUP M65 20
Checkpoint @ $8E0B A:$00, X:$1B, Y:$20, Z:$00, P:$37 :BGOK drce: not
longname
Checkpoint @ $8EB9 A:$20, X:$04, Y:$0B, Z:$03, P:$35 :BGOK drce_fl
populated fields
Checkpoint @ $8F03 A:$40, X:$04, Y:$10, Z:$03, P:$35 :BGOK drce_not_eof
<1/3>
Checkpoint @ $8F27 A:$0A, X:$04, Y:$10, Z:$03, P:$35 :BGOK drce_not_eof
<2/3>
Checkpoint @ $8F4E A:$4B, X:$04, Y:$10, Z:$03, P:$35 :BGOK drce_not_eof
<3/3>
Checkpoint @ $8F8B A:$4B, X:$41, Y:$30, Z:$03, P:$34 :LFN(0A):
KICKUP.M65????????????????????
Checkpoint @ $8BB1 A:$30, X:$30, Y:$30, Z:$03, P:$34
:dos_readdir[0040]======================
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $8C5B A:$30, X:$1B, Y:$32, Z:$00, P:$34 :BGOK (8.3)+ATTRIB
=MEGA65 ROM 20
Checkpoint @ $8E0B A:$00, X:$1B, Y:$20, Z:$00, P:$37 :BGOK drce: not
longname
Checkpoint @ $8EB9 A:$20, X:$04, Y:$0B, Z:$03, P:$35 :BGOK drce_fl
populated fields
Checkpoint @ $8F03 A:$60, X:$04, Y:$10, Z:$03, P:$35 :BGOK drce_not_eof
<1/3>
Checkpoint @ $8F27 A:$0A, X:$04, Y:$10, Z:$03, P:$35 :BGOK drce_not_eof
<2/3>
Checkpoint @ $8F4E A:$4D, X:$04, Y:$10, Z:$03, P:$35 :BGOK drce_not_eof
<3/3>
Checkpoint @ $8F8B A:$4D, X:$41, Y:$30, Z:$03, P:$34 :LFN(0A):
MEGA65.ROM????????????????????
Checkpoint @ $8BB1 A:$30, X:$30, Y:$30, Z:$03, P:$34
:dos_readdir[0060]======================
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $8C5B A:$30, X:$1B, Y:$32, Z:$00, P:$34 :BGOK (8.3)+ATTRIB
=BIT4F0B BIT 20
Checkpoint @ $8E0B A:$00, X:$1B, Y:$20, Z:$00, P:$37 :BGOK drce: not
longname
Checkpoint @ $8EB9 A:$20, X:$04, Y:$0B, Z:$03, P:$35 :BGOK drce_fl
populated fields
Checkpoint @ $8F03 A:$80, X:$04, Y:$10, Z:$03, P:$F5 :BGOK drce_not_eof
<1/3>
Checkpoint @ $8F27 A:$0B, X:$04, Y:$10, Z:$03, P:$35 :BGOK drce_not_eof
<2/3>
Checkpoint @ $8F4E A:$42, X:$04, Y:$10, Z:$03, P:$35 :BGOK drce_not_eof
<3/3>
Checkpoint @ $8F8B A:$42, X:$42, Y:$30, Z:$03, P:$34 :LFN(0B):
BIT4F0B.BIT???????????????????
Checkpoint @ $8BB1 A:$30, X:$30, Y:$30, Z:$03, P:$34
:dos_readdir[0080]======================
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $8C5B A:$30, X:$1B, Y:$32, Z:$00, P:$34 :BGOK (8.3)+ATTRIB
=BOOTLOGOM65 20
Checkpoint @ $8E0B A:$00, X:$1B, Y:$20, Z:$00, P:$37 :BGOK drce: not
longname
Checkpoint @ $8EB9 A:$20, X:$04, Y:$0B, Z:$03, P:$35 :BGOK drce_fl
populated fields
Checkpoint @ $8F03 A:$A0, X:$04, Y:$10, Z:$03, P:$B5 :BGOK drce_not_eof
<1/3>
Checkpoint @ $8F27 A:$0C, X:$04, Y:$10, Z:$03, P:$35 :BGOK drce_not_eof
<2/3>
Checkpoint @ $8F4E A:$42, X:$04, Y:$10, Z:$03, P:$35 :BGOK drce_not_eof
<3/3>
Checkpoint @ $8F8B A:$42, X:$43, Y:$30, Z:$03, P:$34 :LFN(0C):
BOOTLOGO.M65??????????????????
Checkpoint @ $8BB1 A:$30, X:$30, Y:$30, Z:$03, P:$34
:dos_readdir[00A0]======================
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $8C5B A:$30, X:$1B, Y:$32, Z:$00, P:$34 :BGOK (8.3)+ATTRIB
=CHARROM M65 20
Checkpoint @ $8E0B A:$00, X:$1B, Y:$20, Z:$00, P:$37 :BGOK drce: not
longname
Checkpoint @ $8EB9 A:$20, X:$04, Y:$0B, Z:$03, P:$35 :BGOK drce_fl
populated fields
Checkpoint @ $8F03 A:$C0, X:$04, Y:$10, Z:$03, P:$B5 :BGOK drce_not_eof
<1/3>
Checkpoint @ $8F27 A:$0B, X:$04, Y:$10, Z:$03, P:$35 :BGOK drce_not_eof
<2/3>
Checkpoint @ $8F4E A:$43, X:$04, Y:$10, Z:$03, P:$35 :BGOK drce_not_eof
<3/3>
Checkpoint @ $8F8B A:$43, X:$42, Y:$30, Z:$03, P:$34 :LFN(0B):
CHARROM.M65???????????????????
Checkpoint @ $8FFE A:$48, X:$00, Y:$30, Z:$03, P:$37 :Found the file...

@
@ found it, and loads it into memory
@

Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=0060D800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=0060DA00.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=0060DC00.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=0060DE00.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=0060E000.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=0060E200.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=0060E400.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=0060E600.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00147E00.
Checkpoint @ $91C5 A:$0F, X:$40, Y:$1A, Z:$04, P:$37 :WARN: PRINTHEX in
dfanc_check
Checkpoint @ $9AC8 A:$00, X:$10, Y:$16, Z:$00, P:$37 : OK-loading CHARROM
Checkpoint @ $9B05 A:$30, X:$00, Y:$30, Z:$10, P:$34 : try-loading
MEGA65-ROM

@
@ now search for and load MEGA65.ROM, its a big file so i will delete some lines
@

Checkpoint @ $926E A:$06, X:$0F, Y:$2C, Z:$3F, P:$35
:dos_print_current_cluster
Checkpoint @ $8BB1 A:$30, X:$30, Y:$30, Z:$3F, P:$34
:dos_readdir[0000]======================
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $8C5B A:$38, X:$1B, Y:$30, Z:$00, P:$34 :BGOK (8.3)+ATTRIB
=LOUD        08
Checkpoint @ $8CBB A:$00, X:$1B, Y:$08, Z:$00, P:$37 : is Volume ID, so
skip this record
Checkpoint @ $8BB1 A:$30, X:$30, Y:$30, Z:$00, P:$34
:dos_readdir[0020]======================
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $8C5B A:$30, X:$1B, Y:$32, Z:$00, P:$34 :BGOK (8.3)+ATTRIB
=KICKUP M65 20
Checkpoint @ $8E0B A:$00, X:$1B, Y:$20, Z:$00, P:$37 :BGOK drce: not
longname
Checkpoint @ $8EB9 A:$20, X:$04, Y:$0B, Z:$03, P:$35 :BGOK drce_fl
populated fields
Checkpoint @ $8F03 A:$40, X:$04, Y:$10, Z:$03, P:$35 :BGOK drce_not_eof
<1/3>
Checkpoint @ $8F27 A:$0A, X:$04, Y:$10, Z:$03, P:$35 :BGOK drce_not_eof
<2/3>
Checkpoint @ $8F4E A:$4B, X:$04, Y:$10, Z:$03, P:$35 :BGOK drce_not_eof
<3/3>
Checkpoint @ $8F8B A:$4B, X:$41, Y:$30, Z:$03, P:$34 :LFN(0A):
KICKUP.M65????????????????????
Checkpoint @ $8BB1 A:$30, X:$30, Y:$30, Z:$03, P:$34
:dos_readdir[0040]======================
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00240800.
Checkpoint @ $8C5B A:$30, X:$1B, Y:$32, Z:$00, P:$34 :BGOK (8.3)+ATTRIB
=MEGA65 ROM 20
Checkpoint @ $8E0B A:$00, X:$1B, Y:$20, Z:$00, P:$37 :BGOK drce: not
longname
Checkpoint @ $8EB9 A:$20, X:$04, Y:$0B, Z:$03, P:$35 :BGOK drce_fl
populated fields
Checkpoint @ $8F03 A:$60, X:$04, Y:$10, Z:$03, P:$35 :BGOK drce_not_eof
<1/3>
Checkpoint @ $8F27 A:$0A, X:$04, Y:$10, Z:$03, P:$35 :BGOK drce_not_eof
<2/3>
Checkpoint @ $8F4E A:$4D, X:$04, Y:$10, Z:$03, P:$35 :BGOK drce_not_eof
<3/3>
Checkpoint @ $8F8B A:$4D, X:$41, Y:$30, Z:$03, P:$34 :LFN(0A):
MEGA65.ROM????????????????????
Checkpoint @ $8FFE A:$45, X:$00, Y:$30, Z:$03, P:$37 :Found the file...
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00245800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00245A00.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00245C00.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00245E00.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00246000.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00246200.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00246400.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00246600.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00147000.
Checkpoint @ $91C5 A:$00, X:$20, Y:$1A, Z:$04, P:$37 :WARN: PRINTHEX in
dfanc_check
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00246800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00246A00.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00246C00.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00246E00.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00247000.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00247200.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00247400.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00247600.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00147000.
Checkpoint @ $91C5 A:$00, X:$24, Y:$1A, Z:$04, P:$37 :WARN: PRINTHEX in
dfanc_check
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00247800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00247A00.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00247C00.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00247E00.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00248000.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00248200.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00248400.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00248600.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00147000.
Checkpoint @ $91C5 A:$00, X:$98, Y:$1A, Z:$04, P:$37 :WARN: PRINTHEX in
dfanc_check
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00264800.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00264A00.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00264C00.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00264E00.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00265000.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00265200.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00265400.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00265600.
Checkpoint @ $9D00 A:$30, X:$30, Y:$30, Z:$00, P:$34
:sd_read(ing)sector: $d681=00147000.
Checkpoint @ $91C5 A:$0F, X:$9C, Y:$1A, Z:$04, P:$37 :WARN: PRINTHEX in
dfanc_check
Checkpoint @ $9B88 A:$00, X:$00, Y:$19, Z:$3F, P:$35 : OK-loading
MEGA65-ROM

PC A X Y Z B SP MAPL MAPH LAST-OP P P-FLAGS RGP uS IO

9A99 20 15 00 B0 00 01F1 1100 3180 AD 82 D0 24 00 ..E..I... ..P 50 -00 --
.

Ben-401

unread,

Sep 6, 2016, 9:10:27 PM9/6/16

to C65GS Development

i see that the boot-log got truncated.
I may post this in the doc/readme.md for reference, at some later stage.

Ben-401

unread,

Sep 26, 2016, 5:06:33 AM9/26/16

to C65GS Development

I have uploaded my recent changes to the HEAD of DEVELOPMENT.
The code now seems to read consistently from a sdcard formatted with the script.
I have found a number of things, some of which are mentioned here:

Yes the end-of-directory marker now seems working (Thanks Paul and LGB)
This means that file-not-found is also now detected.

Implemented now are detections for Directories, Hidden and System files, all of which are ignored with this fat32 implementation.

Long file names are also ignored, but the code remains because it is expected that this will be developed later on.

Ben-401

unread,

Sep 26, 2016, 5:12:31 AM9/26/16

to C65GS Development

I have found that after formatting the sdcard, the following files are only needed on the card:
MEGA65.ROM
A.BIT (where A is a short filename)

CHARROM.M65 is optional, but fonts and colors are messed up without it.
BOOTLOGO.M65 is optional, this is just used at the boot screen.
MEGA65.D81 is optional, but is strongly suggested to have because the 'utilities' are on that image, and currently the Disk-Mount-utility to mount any other image is on that image. So, without having the MEGA65.D81 mounted at startup, I cannot see a way to load the Disk-Mount-utility any other way.

All files on the card that are targets of the kickup-load-routine should be in 8.3 format, UPPERcase.

Ben-401

unread,

Sep 26, 2016, 5:23:47 AM9/26/16

to C65GS Development

Also of interest, I have changed the number of reserved sectors (within the setcard-script) from 568 to 566 then to 32, and created a new sdcard. After placing the files on the card, the MEGA65 boots up just fine, and it can be seen that the sectors/clusters used during the load are smaller-in-size to when the number-of-reserved-sectors was 568. This is expected and simply a verification that the target-files are now in different locations on the card.

So it seems the kickup is happy to load from a sdcard when reserved sectors set to 32.
BUT, after dropping into c65 or c64 mode, the filesystem is not happy.

I think this is due to the hardcoded offsets used in the current implementation for #_reserved_sectors (#RS).
I have discussed some of this in the doco/fat32.md
I have also highlighted some areas that I do not agree with the calculations.

My position is that currently with the filesystem set to #RS=568, things work good enough. We seem to be able to load.

Saving to the card is probably the next issue, which if I took upon this task, I would expect to have to completely understand the calculations referred to above, ie the ones that I dont agree/understand.

Ben-401

unread,

Oct 3, 2016, 9:35:54 PM10/3/16

to C65GS Development

URGH, more problems with the format of the sdcard.
For completeness, below are the details of the sdcard that Paul used during his development:

Disk /dev/sdc: 1.9 GiB, 2002780160 bytes, 3911680 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device Boot Start End Sectors Size Id Type
/dev/sdc1 129 3911679 3911551 1.9G b W95 FAT32

================================
fsck.fat 3.0.28 (2015-05-16)
fsck.fat 3.0.28 (2015-05-16)
Checking we can access the last sector of the filesystem
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
Automatically removing dirty bit.

Boot sector contents:
System ID "MSDOS5.0"
Media byte 0xf8 (hard disk)
       512 bytes per logical sector
      4096 bytes per cluster
       568 reserved sectors
First FAT starts at byte 290816 (sector 568)
         2 FATs, 32 bit entries
   1951744 bytes per FAT (= 3812 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 4194304 (sector 8192)
    487919 data clusters (1998516224 bytes)
63 sectors/track, 255 heads
       129 hidden sectors
   3911551 sectors total
FATs differ but appear to be intact. Using first FAT.
Checking for unused clusters.
Checking free cluster summary.
Leaving filesystem unchanged.

/dev/sdc1: 127 files, 9676/487919 clusters

And unfortunately, I have since formatted his card, but before I formatted I grabbed the image of the first 100MB or so, and here are some relevant sections:

MBR:
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 |................|
000001c0 04 00 0b 0a ca ca 81 00 00 00 7f af 3b 00 00 00 |............;...|
000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

Vol-ID
00010200 eb 58 90 4d 53 44 4f 53 35 2e 30 00 02 08 38 02 |.X.MSDOS5.0...8.|
00010210 02 00 00 00 00 f8 00 00 3f 00 ff 00 81 00 00 00 |........?.......|
00010220 7f af 3b 00 e4 0e 00 00 00 00 00 00 02 00 00 00 |..;.............|
00010230 01 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00010240 80 01 29 aa cd 2f 2c 4e 4f 20 4e 41 4d 45 20 20 |..)../,NO NAME |
00010250 20 20 46 41 54 33 32 20 20 20 33 c9 8e d1 bc f4 | FAT32   3.....|
00010260 7b 8e c1 8e d9 bd 00 7c 88 4e 02 8a 56 40 b4 41 |{......|.N..V@.A|
00010270 bb aa 55 cd 13 72 10 81 fb 55 aa 75 0a f6 c1 01 |..U..r...U.u....|
00010280 74 05 fe 46 02 eb 2d 8a 56 40 b4 08 cd 13 73 05 |t..F..-.V@....s.|
00010290 b9 ff ff 8a f1 66 0f b6 c6 40 66 0f b6 d1 80 e2 |.....f...@f.....|
000102a0 3f f7 e2 86 cd c0 ed 06 41 66 0f b7 c9 66 f7 e1 |?.......Af...f..|
000102b0 66 89 46 f8 83 7e 16 00 75 38 83 7e 2a 00 77 32 |f.F..~..u8.~*.w2|
000102c0 66 8b 46 1c 66 83 c0 0c bb 00 80 b9 01 00 e8 2b |f.F.f..........+|
000102d0 00 e9 2c 03 a0 fa 7d b4 7d 8b f0 ac 84 c0 74 17 |..,...}.}.....t.|
000102e0 3c ff 74 09 b4 0e bb 07 00 cd 10 eb ee a0 fb 7d |<.t............}|
000102f0 eb e5 a0 f9 7d eb e0 98 cd 16 cd 19 66 60 80 7e |....}.......f`.~|
00010300 02 00 0f 84 20 00 66 6a 00 66 50 06 53 66 68 10 |.... .fj.fP.Sfh.|
00010310 00 01 00 b4 42 8a 56 40 8b f4 cd 13 66 58 66 58 |....B.V@....fXfX|
00010320 66 58 66 58 eb 33 66 3b 46 f8 72 03 f9 eb 2a 66 |fXfX.3f;F.r...*f|
00010330 33 d2 66 0f b7 4e 18 66 f7 f1 fe c2 8a ca 66 8b |3.f..N.f......f.|
00010340 d0 66 c1 ea 10 f7 76 1a 86 d6 8a 56 40 8a e8 c0 |.f....v....V@...|
00010350 e4 06 0a cc b8 01 02 cd 13 66 61 0f 82 75 ff 81 |.........fa..u..|
00010360 c3 00 02 66 40 49 75 94 c3 42 4f 4f 54 4d 47 52 |...f@Iu..BOOTMGR|
00010370 20 20 20 20 00 00 00 00 00 00 00 00 00 00 00 00 |    ............|
00010380 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00010390 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000103a0 00 00 00 00 00 00 00 00 00 00 00 00 0d 0a 52 65 |..............Re|
000103b0 6d 6f 76 65 20 64 69 73 6b 73 20 6f 72 20 6f 74 |move disks or ot|
000103c0 68 65 72 20 6d 65 64 69 61 2e ff 0d 0a 44 69 73 |her media....Dis|
000103d0 6b 20 65 72 72 6f 72 ff 0d 0a 50 72 65 73 73 20 |k error...Press |
000103e0 61 6e 79 20 6b 65 79 20 74 6f 20 72 65 73 74 61 |any key to resta|
000103f0 72 74 0d 0a 00 00 00 00 00 ac cb d8 00 00 55 aa |rt............U.|
00010400 52 52 61 41 00 00 00 00 00 00 00 00 00 00 00 00 |RRaA............|

00010e00 eb 58 90 4d 53 44 4f 53 35 2e 30 00 02 08 38 02 |.X.MSDOS5.0...8.|
00010e10 02 00 00 00 00 f8 00 00 3f 00 ff 00 81 00 00 00 |........?.......|
00010e20 7f af 3b 00 e4 0e 00 00 00 00 00 00 02 00 00 00 |..;.............|
00010e30 01 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00010e40 80 00 29 aa cd 2f 2c 4e 4f 20 4e 41 4d 45 20 20 |..)../,NO NAME |
00010e50 20 20 46 41 54 33 32 20 20 20 33 c9 8e d1 bc f4 | FAT32   3.....|
00010e60 7b 8e c1 8e d9 bd 00 7c 88 4e 02 8a 56 40 b4 41 |{......|.N..V@.A|
00010e70 bb aa 55 cd 13 72 10 81 fb 55 aa 75 0a f6 c1 01 |..U..r...U.u....|
00010e80 74 05 fe 46 02 eb 2d 8a 56 40 b4 08 cd 13 73 05 |t..F..-.V@....s.|
00010e90 b9 ff ff 8a f1 66 0f b6 c6 40 66 0f b6 d1 80 e2 |.....f...@f.....|
00010ea0 3f f7 e2 86 cd c0 ed 06 41 66 0f b7 c9 66 f7 e1 |?.......Af...f..|
00010eb0 66 89 46 f8 83 7e 16 00 75 38 83 7e 2a 00 77 32 |f.F..~..u8.~*.w2|
00010ec0 66 8b 46 1c 66 83 c0 0c bb 00 80 b9 01 00 e8 2b |f.F.f..........+|
00010ed0 00 e9 2c 03 a0 fa 7d b4 7d 8b f0 ac 84 c0 74 17 |..,...}.}.....t.|
00010ee0 3c ff 74 09 b4 0e bb 07 00 cd 10 eb ee a0 fb 7d |<.t............}|
00010ef0 eb e5 a0 f9 7d eb e0 98 cd 16 cd 19 66 60 80 7e |....}.......f`.~|
00010f00 02 00 0f 84 20 00 66 6a 00 66 50 06 53 66 68 10 |.... .fj.fP.Sfh.|
00010f10 00 01 00 b4 42 8a 56 40 8b f4 cd 13 66 58 66 58 |....B.V@....fXfX|
00010f20 66 58 66 58 eb 33 66 3b 46 f8 72 03 f9 eb 2a 66 |fXfX.3f;F.r...*f|
00010f30 33 d2 66 0f b7 4e 18 66 f7 f1 fe c2 8a ca 66 8b |3.f..N.f......f.|
00010f40 d0 66 c1 ea 10 f7 76 1a 86 d6 8a 56 40 8a e8 c0 |.f....v....V@...|
00010f50 e4 06 0a cc b8 01 02 cd 13 66 61 0f 82 75 ff 81 |.........fa..u..|
00010f60 c3 00 02 66 40 49 75 94 c3 42 4f 4f 54 4d 47 52 |...f@Iu..BOOTMGR|
00010f70 20 20 20 20 00 00 00 00 00 00 00 00 00 00 00 00 |    ............|
00010f80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00010f90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00010fa0 00 00 00 00 00 00 00 00 00 00 00 00 0d 0a 52 65 |..............Re|
00010fb0 6d 6f 76 65 20 64 69 73 6b 73 20 6f 72 20 6f 74 |move disks or ot|
00010fc0 68 65 72 20 6d 65 64 69 61 2e ff 0d 0a 44 69 73 |her media....Dis|
00010fd0 6b 20 65 72 72 6f 72 ff 0d 0a 50 72 65 73 73 20 |k error...Press |
00010fe0 61 6e 79 20 6b 65 79 20 74 6f 20 72 65 73 74 61 |any key to resta|
00010ff0 72 74 0d 0a 00 00 00 00 00 ac cb d8 00 00 55 aa |rt............U.|
00011000 52 52 61 41 00 00 00 00 00 00 00 00 00 00 00 00 |RRaA............|

Paul Gardner-Stephen

unread,

Oct 3, 2016, 10:07:31 PM10/3/16

to Ben-401, C65GS Development

What is the problem you are seeing with the format this time around?

Paul.

--

Ben-401

unread,

Oct 3, 2016, 10:13:56 PM10/3/16

to C65GS Development

From the MBR, we see that $01BE+[8..B] = $00000081 = partition_lba_begin

We then multiply "partition_lba_begin" by $200 which gives the offset to Vol-ID
$81 x $200 = $00010200 = Vol-ID of partition#1

Shown above from $00010200 to $00010200+$200=$00010400 is the Vol-ID.

From the following offsets, we get the following:
Vol-ID +0B,0C = $0200 =

bytes_per_sector ($0200=#512)

Vol-ID +0D = $08 = sectors_per_cluster (#08)

Vol-ID +0E,0F = $0238 = number_reserved_sectors ($0238=#568)
Vol-ID +10 = $02 = number_of_FATs (#02)
Vol-ID +24..27= $0EE4 = sectors_per_FAT ($00000EE4=#EE4)
Vol-ID +2C..2F= $0002 = root_dir_first_cluster ($00000002)

Comparing the above, the following comments are made:

bytes_per_sector ($0200=#512)        SAME as FDISK

sectors_per_cluster (#08)

            SAME as FDISK (#4096 bytes/cluster = 8*#512)

number_reserved_sectors ($0238=#568) SAME as FDISK
number_of_FATs (#02)                 SAME as FDISK
sectors_per_FAT ($00000EE4=#3812)    SAME, ie #3812x$200=#1,951,755
sectors_per_FAT ($00000002)          SAME as FDISK

We then use the following formula to know where the FAT is:
number_reserved_sectors + (number_of_FATs *

sectors_per_FAT)
= $568                    + (2              * EE4)
= $2000
= #8192'nd sector  => SAME as FDISK

Now, we need to consider the "#8192" as an offset from the Vol-ID @ $00010200
So, FAT = $00010200 + $00400000 = $00410200

Ben-401

unread,

Oct 3, 2016, 10:16:06 PM10/3/16

to C65GS Development

And so here is the FAT from Pauls sdcard:

00410200 46 50 47 41 2d 42 4f 41 52 44 20 08 00 00 00 00 |FPGA-BOARD .....|
00410210 00 00 00 00 00 00 ba 88 17 49 00 00 00 00 00 00 |.........I......|
00410220 42 4f 4f 54 4c 4f 47 4f 4d 36 35 20 00 9b 51 74 |BOOTLOGOM65 ..Qt|
00410230 0f 49 11 49 00 00 e6 1c 0a 49 03 00 00 10 00 00 |.I.I.....I......|
00410240 43 48 41 52 52 4f 4d 20 4d 36 35 20 00 3e 54 74 |CHARROM M65 .>Tt|
00410250 0f 49 11 49 00 00 9c 4e ed 46 82 2c 00 10 00 00 |.I.I...N.F.,....|
00410260 44 45 4d 4f 20 20 20 20 44 38 31 20 00 b8 62 74 |DEMO    D81 ..bt|
00410270 0f 49 11 49 00 00 af 26 db 48 49 2d 00 80 0c 00 |.I.I...&.HI-....|
00410280 50 47 53 20 20 20 20 20 44 38 31 20 18 bf 66 74 |PGS     D81 ..ft|
00410290 0f 49 11 49 00 00 11 0b 0c 49 cd 00 00 80 0c 00 |.I.I.....I......|
004102a0 4d 45 47 41 36 35 20 20 52 4f 4d 20 00 bc 68 74 |MEGA65 ROM ..ht|
004102b0 0f 49 16 49 00 00 98 7e 16 49 f8 56 00 00 02 00 |.I.I...~.I.V....|
004102c0 4d 45 47 41 36 35 20 20 44 38 31 20 00 17 03 79 |MEGA65 D81 ...y|
004102d0 11 49 11 49 00 00 03 79 11 49 7c 55 00 80 0c 00 |.I.I...y.I|U....|
004102e0 41 2e 00 66 00 73 00 65 00 76 00 0f 00 da 65 00 |A..f.s.e.v....e.|
004102f0 6e 00 74 00 73 00 64 00 00 00 00 00 ff ff ff ff |n.t.s.d.........|
00410300 46 53 45 56 45 4e 7e 31 20 20 20 12 00 8a b8 88 |FSEVEN~1   .....|
00410310 17 49 17 49 00 00 b8 88 17 49 87 56 00 00 00 00 |.I.I.....I.V....|
00410320 52 45 53 54 4f 52 45 20 42 49 54 20 18 12 6f 6a |RESTORE BIT ..oj|
00410330 12 49 16 49 00 00 23 59 17 49 a4 51 ec 60 3a 00 |.I.I..#Y.I.Q.`:.|
00410340 46 4f 55 4e 44 20 20 20 30 30 30 06 00 00 2a 76 |FOUND   000...*v|
00410350 0f 49 0f 49 00 00 2a 76 0f 49 00 00 00 00 00 00 |.I.I..*v.I......|
00410360 43 38 00 31 00 00 00 ff ff ff ff 0f 00 60 ff ff |C8.1.........`..|
00410370 ff ff ff ff ff ff ff ff ff ff 00 00 ff ff ff ff |................|
00410380 02 75 00 69 00 6c 00 61 00 53 00 0f 00 60 75 00 |.u.i.l.a.S...`u.|
00410390 6e 00 72 00 69 00 73 00 65 00 00 00 2e 00 64 00 |n.r.i.s.e.....d.|
004103a0 01 42 00 6c 00 61 00 63 00 6b 00 0f 00 60 4d 00 |.B.l.a.c.k...`M.|
004103b0 61 00 69 00 6c 00 2d 00 54 00 00 00 65 00 71 00 |a.i.l.-.T...e.q.|
004103c0 42 4c 41 43 4b 4d 7e 31 44 38 31 20 00 0e 78 76 |BLACKM~1D81 ..xv|
004103d0 0f 49 11 49 00 00 11 0b 0c 49 db 28 00 80 0c 00 |.I.I.....I.(....|
004103e0 41 63 00 72 00 65 00 73 00 74 00 0f 00 b3 32 00 |Ac.r.e.s.t....2.|
004103f0 79 00 72 00 73 00 2e 00 64 00 00 00 38 00 31 00 |y.r.s...d...8.1.|
00410400 43 52 45 53 54 32 7e 31 44 38 31 20 00 39 78 76 |CREST2~1D81 .9xv|
00410410 0f 49 11 49 00 00 11 0b 0c 49 a3 29 00 80 0c 00 |.I.I.....I.)....|
00410420 42 38 00 31 00 00 00 ff ff ff ff 0f 00 01 ff ff |B8.1............|
00410430 ff ff ff ff ff ff ff ff ff ff 00 00 ff ff ff ff |................|
00410440 01 44 00 65 00 6d 00 6f 00 73 00 0f 00 01 39 00 |.D.e.m.o.s....9.|
00410450 30 00 30 00 39 00 30 00 37 00 00 00 2e 00 64 00 |0.0.9.0.7.....d.|
00410460 44 45 4d 4f 53 39 7e 31 44 38 31 20 00 59 78 76 |DEMOS9~1D81 .Yxv|
00410470 0f 49 11 49 00 00 11 0b 0c 49 6b 2a 00 80 0c 00 |.I.I.....Ik*....|
00410480 42 38 00 31 00 00 00 ff ff ff ff 0f 00 21 ff ff |B8.1.........!..|
00410490 ff ff ff ff ff ff ff ff ff ff 00 00 ff ff ff ff |................|
004104a0 01 44 00 65 00 6d 00 6f 00 73 00 0f 00 21 39 00 |.D.e.m.o.s...!9.|
004104b0 31 00 30 00 36 00 31 00 30 00 00 00 2e 00 64 00 |1.0.6.1.0.....d.|
004104c0 44 45 4d 4f 53 39 7e 32 44 38 31 20 00 6e 78 76 |DEMOS9~2D81 .nxv|
004104d0 0f 49 11 49 00 00 11 0b 0c 49 33 2b 00 80 0c 00 |.I.I.....I3+....|
004104e0 4c 45 4d 4d 49 4e 47 53 44 38 31 20 18 7f 78 76 |LEMMINGSD81 ..xv|
004104f0 0f 49 11 49 00 00 11 0b 0c 49 fb 2b 00 70 08 00 |.I.I.....I.+.p..|
00410500 4f 4c 44 20 20 20 20 20 20 20 20 10 08 94 78 76 |OLD        ...xv|
00410510 0f 49 0f 49 00 00 d2 53 0f 49 c3 2c 00 00 00 00 |.I.I...S.I.,....|
00410520 42 49 54 53 20 20 20 20 20 20 20 10 08 64 20 2b |BITS       ..d +|
00410530 0f 49 0f 49 00 00 20 2b 0f 49 38 31 00 00 00 00 |.I.I.. +.I81....|
00410540 31 20 20 20 20 20 20 20 44 38 31 20 10 4a 7b 76 |1       D81 .J{v|
00410550 0f 49 11 49 00 00 11 0b 0c 49 ca 4a 00 80 0c 00 |.I.I.....I.J....|
00410560 e5 49 43 4b 55 50 20 20 4d 36 35 20 00 ad 80 80 |.ICKUP M65 ....|
00410570 16 49 17 49 00 00 64 87 17 49 9d 56 00 40 00 00 |.I.I..d..I.V.@..|
00410580 41 2e 00 5f 00 2e 00 54 00 72 00 0f 00 7f 61 00 |A.._...T.r....a.|
00410590 73 00 68 00 65 00 73 00 00 00 00 00 ff ff ff ff |s.h.e.s.........|
004105a0 7e 31 20 20 20 20 20 20 54 52 41 22 00 a5 4d 7c |~1      TRA"..M||
004105b0 0f 49 17 49 00 00 4d 7c 0f 49 a1 4f 00 10 00 00 |.I.I..M|.I.O....|
004105c0 55 54 49 4c 49 54 59 20 44 38 31 20 18 46 57 7c |UTILITY D81 .FW||
004105d0 0f 49 11 49 00 00 57 7c 0f 49 a0 50 00 80 0c 00 |.I.I..W|.I.P....|
004105e0 41 2e 00 54 00 72 00 61 00 73 00 0f 00 25 68 00 |A..T.r.a.s...%h.|
004105f0 65 00 73 00 00 00 ff ff ff ff 00 00 ff ff ff ff |e.s.............|
00410600 54 52 41 53 48 45 7e 31 20 20 20 12 00 a5 4d 7c |TRASHE~1   ...M||
00410610 0f 49 0f 49 00 00 4d 7c 0f 49 a0 4f 00 00 00 00 |.I.I..M|.I.O....|
00410620 41 2e 00 5f 00 4d 00 45 00 47 00 0f 00 9e 41 00 |A.._.M.E.G....A.|
00410630 36 00 35 00 2e 00 52 00 4f 00 00 00 4d 00 00 00 |6.5...R.O...M...|
00410640 5f 4d 45 47 41 36 7e 31 52 4f 4d 22 00 39 98 7e |_MEGA6~1ROM".9.~|
00410650 16 49 16 49 00 00 98 7e 16 49 6b 56 00 10 00 00 |.I.I...~.IkV....|
00410660 42 30 00 30 00 00 00 ff ff ff ff 0f 00 21 ff ff |B0.0.........!..|
00410670 ff ff ff ff ff ff ff ff ff ff 00 00 ff ff ff ff |................|
00410680 01 2e 00 53 00 70 00 6f 00 74 00 0f 00 21 6c 00 |...S.p.o.t...!l.|
00410690 69 00 67 00 68 00 74 00 2d 00 00 00 56 00 31 00 |i.g.h.t.-...V.1.|
004106a0 53 50 4f 54 4c 49 7e 31 20 20 20 12 00 b5 4d 7c |SPOTLI~1   ...M||
004106b0 0f 49 0f 49 00 00 4d 7c 0f 49 a4 4f 00 00 00 00 |.I.I..M|.I.O....|
004106c0 e5 31 00 35 00 36 00 62 00 34 00 0f 00 6b 64 00 |.1.5.6.b.4...kd.|
004106d0 36 00 7e 00 2e 00 62 00 69 00 00 00 74 00 00 00 |6.~...b.i...t...|
004106e0 e5 62 00 69 00 74 00 30 00 38 00 0f 00 6b 31 00 |.b.i.t.0.8...k1.|
004106f0 37 00 5f 00 31 00 30 00 35 00 00 00 30 00 5f 00 |7._.1.0.5...0._.|
00410700 e5 49 54 30 38 31 7e 32 42 49 54 20 00 63 61 60 |.IT081~2BIT .ca`|
00410710 11 49 11 49 00 00 61 60 11 49 70 51 ec 60 3a 00 |.I.I..a`.IpQ.`:.|
00410720 e5 64 00 31 00 31 00 65 00 37 00 0f 00 cb 33 00 |.d.1.1.e.7....3.|
00410730 31 00 7e 00 2e 00 62 00 69 00 00 00 74 00 00 00 |1.~...b.i...t...|
00410740 e5 62 00 69 00 74 00 30 00 38 00 0f 00 cb 31 00 |.b.i.t.0.8....1.|
00410750 37 00 5f 00 31 00 34 00 35 00 00 00 37 00 5f 00 |7._.1.4.5...7._.|
00410760 e5 49 54 30 38 31 7e 31 42 49 54 20 00 08 ee 7d |.IT081~1BIT ...}|
00410770 11 49 11 49 00 00 ee 7d 11 49 8c 56 ec 60 3a 00 |.I.I...}.I.V.`:.|
00410780 4b 49 43 4b 55 50 20 20 4d 36 35 20 00 48 e1 73 |KICKUP M65 .H.s|
00410790 1a 49 1a 49 00 00 01 25 1a 49 04 00 00 40 00 00 |.I.I...%.I...@..|
004107a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
004107b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
004107c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
004107d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

Paul Gardner-Stephen

unread,

Oct 3, 2016, 10:31:23 PM10/3/16

to Ben-401, C65GS Development

Hello,

Try the fat32.c program on each image you have to see if it gives the expected values. We need to see where the disagreement is between image, "real" fdisk/fsck, fat32.c and what the kickstart ROM thinks.

Paul.

--

Ben-401

unread,

Oct 3, 2016, 10:38:52 PM10/3/16

to C65GS Development

And here are the relevant details of a 2G card that has just been "set" using the set-card script:

=========================
New layout
Disk /dev/sdc: 1.9 GiB, 1977614336 bytes, 3862528 sectors

Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos

Disk identifier: 0x516a9fea

Device Boot Start End Sectors Size Id Type

/dev/sdc1 2048 1026047 1024000 500M c W95 FAT32 (LBA)

=========================
New format of partition '1'

fsck.fat 3.0.28 (2015-05-16)
Checking we can access the last sector of the filesystem

Boot sector contents:
System ID "mkfs.fat"

Media byte 0xf8 (hard disk)
       512 bytes per logical sector
      4096 bytes per cluster
       568 reserved sectors
First FAT starts at byte 290816 (sector 568)
         2 FATs, 32 bit entries

510976 bytes per FAT (= 998 sectors)

Root directory start at cluster 2 (arbitrary size)

Data area starts at byte 1312768 (sector 2564)
    127679 data clusters (522973184 bytes)
62 sectors/track, 61 heads
       129 hidden sectors
   1024000 sectors total

Checking for unused clusters.
Checking free cluster summary.

/dev/sdc1: 1 files, 1/127679 clusters

MBR
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001b0 00 00 00 00 00 00 00 00 ea 9f 6a 51 00 00 00 21 |..........jQ...!|
000001c0 03 00 0c 12 4a 0f 00 08 00 00 00 a0 0f 00 00 00 |....J...........|
000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

VOL-ID
00100000 eb 58 90 6d 6b 66 73 2e 66 61 74 00 02 08 38 02 |.X.mkfs.fat...8.|
00100010 02 00 00 00 00 f8 00 00 3e 00 3d 00 81 00 00 00 |........>.=.....|
00100020 00 a0 0f 00 e6 03 00 00 00 00 00 00 02 00 00 00 |................|
00100030 01 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00100040 80 00 29 e2 f0 67 23 4c 4f 55 44 20 20 20 20 20 |..)..g#LOUD     |
00100050 20 20 46 41 54 33 32 20 20 20 0e 1f be 77 7c ac | FAT32   ...w|.|
00100060 22 c0 74 0b 56 b4 0e bb 07 00 cd 10 5e eb f0 32 |".t.V.......^..2|
00100070 e4 cd 16 cd 19 eb fe 54 68 69 73 20 69 73 20 6e |.......This is n|
00100080 6f 74 20 61 20 62 6f 6f 74 61 62 6c 65 20 64 69 |ot a bootable di|
00100090 73 6b 2e 20 20 50 6c 65 61 73 65 20 69 6e 73 65 |sk. Please inse|
001000a0 72 74 20 61 20 62 6f 6f 74 61 62 6c 65 20 66 6c |rt a bootable fl|
001000b0 6f 70 70 79 20 61 6e 64 0d 0a 70 72 65 73 73 20 |oppy and..press |
001000c0 61 6e 79 20 6b 65 79 20 74 6f 20 74 72 79 20 61 |any key to try a|
001000d0 67 61 69 6e 20 2e 2e 2e 20 0d 0a 00 00 00 00 00 |gain ... .......|
001000e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
001000f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00100100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00100110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00100120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00100130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00100140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00100150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00100160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00100170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00100180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00100190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
001001a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
001001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
001001c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
001001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
001001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
001001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00100200 52 52 61 41 00 00 00 00 00 00 00 00 00 00 00 00 |RRaA............|

FAT
00240800 4c 4f 55 44 20 20 20 20 20 20 20 08 00 00 75 66 |LOUD       ...uf|
00240810 44 49 44 49 00 00 75 66 44 49 00 00 00 00 00 00 |DIDI..ufDI......|
00240820 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00240830 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00240840 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00240850 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

Ben-401

unread,

Oct 3, 2016, 11:19:22 PM10/3/16

to C65GS Development

Some differences are:

total number of bytes per card (2002780160 vs 1977614336)

partition size and start,
NOTE that it was intended to have a small (500M) partition, to check what is the smallest partition/sdcard we can support. Also note the start location differs.

/dev/sdc1 129 3911679 3911551 1.9G b W95 FAT32

/dev/sdc1 2048 1026047 1024000 500M c W95 FAT32 (LBA)

number of bytes per fat

1951744 bytes per FAT (= 3812 sectors)

510976 bytes per FAT (= 998 sectors)

data area offset, probably caused by the different FAT size
Data area starts at byte 4194304 (sector 8192)

Data area starts at byte 1312768 (sector 2564)

obviously the data-cluster size differs because the partition is of different size (2G vs 500M)

63 sectors/track, 255 heads
62 sectors/track, 61 heads

Ben-401

unread,

Oct 3, 2016, 11:20:54 PM10/3/16

to C65GS Development

so left as an excercise is:

find out what the kickstart-code is hardcoded to (if any),

find out what is the smallest sdcard we can support,

find out if any of the above differences cause any issues.

Paul Gardner-Stephen

unread,

Oct 3, 2016, 11:49:29 PM10/3/16

to Ben-401, C65GS Development

More specifically, I recommend you get the kickstart code to report what it thinks are these critical values for the file system, so that you can compare it with what is there. We are looking for errors in the interpretation of the file system by the kickstart code.

Paul.

--

Ben-401

unread,

Feb 1, 2017, 12:35:17 AM2/1/17

to C65GS Development, ben.0...@gmail.com, pa...@servalproject.org

Yes, kickstart now (v00.07+) reports details of the file system both:
- on screen, as well as
- DEBUG-messages provided that SW-12 is asserted.

Reply all

Reply to author

Forward