6502.org • View topic - CRC65, A frugal 6502 SBC

View unanswered posts | View active topics

Board index » 6502.org Users Forum » SBC- Series Projects

All times are UTC

CRC65, A frugal 6502 SBC

Page 9 of 10

[ 138 posts ]

Go to page Previous 1 ... 6, 7, 8, 9, 10 Next

Previous topic | Next topic

Author

Message

plasmo

Post subject: Re: CRC65, A frugal 6502 SBC

Posted: Tue Nov 01, 2022 7:59 pm

Joined: Fri Dec 21, 2018 1:05 am
Posts: 1119
Location: Albuquerque NM USA

Larry,
Your CF may be on the hairy edge. How is your board powered? 29.5MHz does draw more power so potentially the voltage is drooping. I've looked into XMODEM code and realize the software transmits status info by default which messes up the ACK/NAK handshake, so you need to run XMODEM in the quiet mode. The command for receive and transmit in quiet mode are:
xmodem rq filename
xmodem sq filename

An easy way to verify your xmodem transfer is to receive a file and then send it back and do a file compare.

Currently I'm tackling a problem associated with xmodem on DOS/65 version 3; xmodem file received on drive other than drive A may see strange garbage on console after the "warm boot" message and sometime the DOS/65 will lock up. This doesn't happen on version 2 of DOS/65.
Bill

Top

okwatts

Post subject: Re: CRC65, A frugal 6502 SBC

Posted: Thu Nov 03, 2022 9:18 pm

Joined: Wed Nov 11, 2020 10:42 pm
Posts: 104
Location: Kelowna Canada

Hi Bill
The voltage looks good on the input side for 29.5 Mhz but I will stay for now at 14.7 Mhz. I have not had problems with xmodem at that speed using the quiet option with xmodem but I have not used it exhaustively.
I did find that DBASIC does load and save programs if you use the following as an example LOAD A:MYBAS etc. MUST INCLUDE drive, but NO Quote marks and NO file extension as it looks for .BAS by default and appends it on save.
Also The format is different from BASIC20A where you do need to surround the filename with quotes and include an extension. I believe you need to leave the drive letter off. The upshot is that you can't easily interchange programs between the two versions as there is an extra 128 bytes included in the DBASIC file format at the beginning as well as the fact that they use slightly different tokens and the programs are stored in tokenized form. I can transfer basic programs to them inside the interpreters by ASCII transfers if you put in enough character and line delays. DBASIC needs more time than BASIC20A. I haven't played with it but BASIC20A looks to have been ported from PET or C-64 and may allow using files to store output in a similar manner. I never had either of those machines and so I am not so sure how to do it. I'm not sure who ported BASIC20A over, perhaps Rich Leary did from his C-64 version of DOS/65.
I'm sure I'll discover more as I go along. I will look at trying to get a Forth going under DOS/65. That may take some time and is of possible dubious value as it likely makes more sense for hardware manipulation rather than large program development. It might be interesting to look at GPASCAL as a possible conversion also but that is a more futuristic goal.
I'm sure there is more fun to be had here.
Larry

Top

plasmo

Post subject: Re: CRC65, A frugal 6502 SBC

Posted: Fri Nov 04, 2022 4:28 pm

Joined: Fri Dec 21, 2018 1:05 am
Posts: 1119
Location: Albuquerque NM USA

Larry,
Could you tell me which brand of CF you are using for 29.5MHz? I'm looking for a second source to the 256MB SanDisk which I'm running out. If 29.5MHz is too close to edge, you can try slightly slower clock like 28.8MHz or 28.6363MHz; the serial port can tolerate 3-4% of frequency deviation.

The CF image of ver3 DOS/65 is the easiest way of getting software into CF, but here is the collection of software and TeraTerm macro, newDOS65CF_v3fast.ttl, that loads various DOS/65 files into a new CF disk. Included in the file collection is a new utility to format the new CF disk. It takes over 6 minutes to do everything at 29.5MHz. It also works at 14.7MHz but a few minutes longer. A YouTube video of the TeraTerm running is here: https://youtu.be/DtIrVBMzIUo The reason for developing this script file is because I have a number of disk-on-module (DOM) and no DOM reader to copy the CF disk image.

I'm playing with the MicroSoft BASIC a bit, trying to port StarTrek to it. I know StarTrek ported OK to Z80 version of the MicroSoft BASIC, but the DOS/65 version is slightly different that phaser and torpedo are not working right.

I'm having quite bit of fun with DOS/65. Even at 14.7MHz DOS/65 is significantly faster than CP/M on 22MHz Z80. DOS/65 is also more efficient in memory usage so even with CRC65 squandering 6K of top memory for I/O and bootstrap, the transient memory size is still 52K. A more efficient design of bootstrap and I/O space can add almost 6K to the transient memory size. Thinking about it...using SD card instead of CF would be cool...
Bill

Attachments:

DOS65V3_serial_upload.zip [192.17 KiB]
Downloaded 67 times

Top

okwatts

Post subject: Re: CRC65, A frugal 6502 SBC

Posted: Fri Nov 04, 2022 6:38 pm

Joined: Wed Nov 11, 2020 10:42 pm
Posts: 104
Location: Kelowna Canada

Hi Bill
I am using a Sandisk as shown in the picture. I would like to use the Lexar 512MB but it is too fast for the CRC. It seems to be ready before I can do a serial boot and even if I flash DOS/65 to it, I get nothing in the terminal window.
The strange thing about the Sandisk 256 is that it has worked at 29.5Mhz for other CRC things but it seems to mostly work for DOS/65 except when doing an extended copy or read but that might just indicate it is close to the edge.
I will try the newer version that you attached and check out that.
Larry

Attachments:

20221104_104517small.jpg [ 245.96 KiB | Viewed 11580 times ]

Top

plasmo

Post subject: Re: CRC65, A frugal 6502 SBC

Posted: Mon Nov 07, 2022 3:43 pm

Joined: Fri Dec 21, 2018 1:05 am
Posts: 1119
Location: Albuquerque NM USA

Larry,
Thanks for the hint about using SanDisk brand. I have few types of SanDisk CF from 64MB to 512MB and they all seem to work well at 29.5MHz. I know I have a Lexar CF, but I just can't find it.

I have created a page for porting DOS/65 to CRC65 where all the source codes are posted.
https://www.retrobrewcomputers.org/doku ... :dos65home

Bill

Top

okwatts

Post subject: Re: CRC65, A frugal 6502 SBC

Posted: Mon Nov 07, 2022 3:58 pm

Joined: Wed Nov 11, 2020 10:42 pm
Posts: 104
Location: Kelowna Canada

Hi Bill Very nice write-up on DOS/65 for the CRC65. I have been trying to go through what CF cards I have and tried a Sandisk 1GB card that doesn't respond in the CRC65 ie no blip of the LED on the CF card. If I image it with DOS/65 I get no response but I have no clue why that is happening (or not!)
My only other cards are low 64MB or smaller ones that won't work at 29.5 Mhz (including 2 from you). The only other CF card I have is a 4 GB but it has a load of photos on it and I would have to save them all and then be wasting nearly all 4 GB of space!
It might be time to scavenge the local thrift stores or eBay for a supply.

PS I am presently running DOS/65 on the CRC65 rev 2 with 65816 in emulation mode at 14.7Mhz plugged into a RC2014 MB with the VGA6448
all seems to be working but obviously nothing on the VGA6448 board is being used.

Top

plasmo

Post subject: Re: CRC65, A frugal 6502 SBC

Posted: Sun Nov 27, 2022 2:45 pm

Joined: Fri Dec 21, 2018 1:05 am
Posts: 1119
Location: Albuquerque NM USA

I was rather shocked by how low voltage-wise can W65C02 operate on this test, so I want to repeat the test with CRC65 which can operates with bare minimum of 6502, RAM, CPLD, and oscillator. Without the compact flash bootstrap, the programs must be serially loaded after every reset which involves a serial loader, monitor, and the memory diagnostic programs so is a pretty good suit of tests. The test is to find voltage limit for different W65C02 operating frequencies. Parts are:
W65C02S6TPG-14
CY7C109-25VC
EPM7064SLC44
Can oscillator
Attached is photo of CRC65 under test.

Code:

CPU frequency   serial bps   voltage just above memory failure      current consumption
29.4912MHz            230400      5.0V                             160mA
22MHz                  115200     3.3V                             70mA
14.7456MHz            115200      2.7V                              39mA
7.3728MHz           57600      2.15V                                20mA
1.8432MHz           14400      2.1V                                16mA

The operating voltage for each frequency is just above the point when memory diagnostic failed (displaying a memory failure message), except the last entry (1.84MHz @2.1V) where the program just quit without a failure message. Since multiple programs were successfully loaded and ran and memory test failure was the point of failure, 6502 is operating until memory access became too slow to support proper operation. This could be a combination of slowing RAM, CPLD, or 6502. The last case at 2.1V is disorderly systematic failure of unknown cause.

Bill

11/28/22 edit, added another entry that 22MHz is the maximum CPU frequency with supply voltage of 3.3V. CPLD design was altered slightly to divide the clock by 12 in order to generate 115200 serial clock with 22MHz.

Attachments:

DSC_70941127.jpg [ 1.07 MiB | Viewed 11353 times ]

Top

plasmo

Post subject: Re: CRC65, A frugal 6502 SBC

Posted: Fri Oct 27, 2023 1:03 pm

Joined: Fri Dec 21, 2018 1:05 am
Posts: 1119
Location: Albuquerque NM USA

There are a number of discussions about "ROM-less" SBC and the associate "blind boot", so I thought I'd add another voice to this topic from a different approach.

Short version is "do it with CF" and "breadboard with CPLD".
------------------------------------------------------------------
TLDR:
Currently CRC65 has a small ROM in CPLD that dual boot either from the CF or from an external serial input. The external serial boot is an useful testing feature I'll explain shortly. I want to explore "blind boot", bootstrapping with stream of opcodes, provided by CF which may be simple enough to realize with discrete TTL logic, but I want to do it with CPLD initially so I can change the design rapidly.

After negation of reset and completion of self test, the CF disk is pre-initialized to access its Master Boot Record. All it needs is a read command (write 0x20 to Command Register), wait for data ready which means 256 words from Master Boot Record are loaded into CF's internal FIFO, then strobe out the FIFO data using the read strobe. The FIFO is designed for high speed data transfer. A state machine can sequence through the these steps then 6502 can execute the opcodes streaming out of the FIFO. This concept of blind boot is well know, but how do I actually do it?

This is where CPLD and alternative serial bootstrapping come in. CPLD allows me to change design rapidly and muntzing it down to the bare minimum for discrete TTL implementation; serial bootstrap gives me an alternative way to bring up 6502 so I can quickly change the contents of Master Boot Record.

Here we go...

Top

plasmo

Post subject: Re: CRC65, A frugal 6502 SBC

Posted: Sun Nov 12, 2023 4:33 am

Joined: Fri Dec 21, 2018 1:05 am
Posts: 1119
Location: Albuquerque NM USA

I decided to add a prototype area to the original CRC65 to make it a 4"x4" pc board. The pc board costs the same, but now I'll have an area for experiments. The first experiment is blind booting via compact flash. First I'll prototype with CPLD because it is easy to change the circuitry. Once it worked in CPLD, I'll build another board that replaces the CPLD with discrete logic on the prototype area.

Here is CF blind boot implemented in CPLD. The CPLD contains two blocks, serial port, and CF blind boot state machine. A 74138 decoder places serial port at $8000-$83FF, CF interface at $8400-$87FF and RAM everywhere else (0-$7FFF, $8800-$FFFF).

I'll skip over the serial port. The CF blind boot state machine is in control immediately after reset. It reads the CF status register ($8407) continuously checking for data[7]=0 & data[6]=1 (Not Busy condition). Once "Not Busy" flip flop is set, it writes the command byte 0x20 to CF command register ($8407) which reads Master Boot Record into 256x16 data FIFO. I should mention that data bus is pulled up/down to value of 0x20 with 2.2K resistors so the write operations will write the data bus value of 0x20 to CF command register. After writing the command, the blind boot state machine continuously reads the CF status register looking for Data_Ready at data[3]. Once the Data_Ready flip flop is set, it is show time!

In the CF data register ($8400) is a FIFO with 256 words (the contents of Master Boot Record) queued up. Every CF read strobe will clock out a word. Previously 6502 was held in wait state with RDY negated until Data_Ready flip flop is set. At that point, RDY is asserted (high) and every 6502 reads in address space $8000-$FFFF will strobe the CF read line. So 6502 is executing the 256 opcode streaming out of the FIFO queue when it is reading in memory space $8000-$FFFF. When accessing $0-$7FFF, 6502 is accessing RAM. Given 6502 is executing instructions from FIFO in high memory and accessing RAM in low memory, FIFO contents are series of "load instruction from CF and store in RAM" and the last 3 bytes of FIFO queue are jump to RAM. At the end of FIFO reads, 6502 starts executing the program loaded in RAM.

When CF's FIFO is empty, the DASP signal negates; the blind boot state machine monitors DASP signal and relinquishes the CF interface back to 6502 at the negation of DASP signal.

Next post I'll describe the bootstrap program in Master Boot Record and how I created it.
Bill

Attachments:

top_scm.pdf [15.71 KiB]
Downloaded 71 times

CF_blind_boot_scm.pdf [18.8 KiB]
Downloaded 67 times

DSC_74701111.jpg [ 1.08 MiB | Viewed 8389 times ]

DSC_74711111.jpg [ 1.39 MiB | Viewed 8389 times ]

Top

gfoot

Post subject: Re: CRC65, A frugal 6502 SBC

Posted: Sun Nov 12, 2023 9:52 am

Joined: Fri Jul 09, 2021 10:12 pm
Posts: 741

Cool, looking forward to seeing the bootstrap program.

Are the PCB manufacturers happy to drill so many holes, is there an extra charge at some point?

Top

plasmo

Post subject: Re: CRC65, A frugal 6502 SBC

Posted: Sun Nov 12, 2023 2:15 pm

Joined: Fri Dec 21, 2018 1:05 am
Posts: 1119
Location: Albuquerque NM USA

I have used JLCPCB and Seeed Studio for PC boards. They have not charged extra for all these drill holes. Amazing, maybe they don't use metal drill bits anymore.
Bill

Top

BigDumbDinosaur

Post subject: Re: CRC65, A frugal 6502 SBC

Posted: Mon Nov 13, 2023 1:13 am

Joined: Thu May 28, 2009 9:46 pm
Posts: 8507
Location: Midwestern USA

plasmo wrote:

I have used JLCPCB and Seeed Studio for PC boards. They have not charged extra for all these drill holes. Amazing, maybe they don't use metal drill bits anymore.
Bill

A lot of board houses have moved to solid carbide drills. Although more fragile than TIN-coated high-speed steel (HSS) or carbide-tipped HSS, carbides last much longer and can be run at higher speeds without being damaged by heat build-up. With being able to get more boards out of a set of drills, per hole costs have come down.

_________________
x86? We ain't got no x86. We don't NEED no stinking x86!

Top

plasmo

Post subject: Re: CRC65, A frugal 6502 SBC

Posted: Mon Nov 13, 2023 2:15 am

Joined: Fri Dec 21, 2018 1:05 am
Posts: 1119
Location: Albuquerque NM USA

Now the blind boot state machine has loaded the contents of master boot record in its read FIFO to be executed by 6502, this is description of the MBR contents.

First part is the 6502 reset vector. Since CF's read FIFO is currently mapped to $8000-$FFFF, the reset vector need to be in high 32K memory. A good vector is the NOP instruction, $EA that places the reset vector at $EAEA. Since there are some uncertainly how many instructions will be fetched after reset, there are 5 NOP instruction followed by illegal instruction $3 that executes in one clock cycle. The single cycle illegal instruction is for synchronization purpose in case the 5th and last $EA is treated as a NOP instruction which takes two cycles to execute; in that case $3 serves as dummy read of the NOP instruction.

Dummy reads following an instruction execution is the biggest worry for blind boot. One byte instruction that takes two clocks to execute such as NOP will need a dummy data following the one byte instruction. I'm using the illegal instruction $3 as the dummy data in my software. Another complication is the dummy data is needed only if the dummy operation is in the memory range of $8000-$FFFF which causes a CF read cycle. If the dummy operation is in the memory range of $0-$7FFF, it is accessing RAM and not causing CF read so dummy data is not needed.

Really, the case-by-case analysis of dummy operation is too complicated for me to manage so I do the bare minimum and do it with a Macro. The idea is to create a small program in RAM using a series of macros then jump to RAM to execute the program normally. I have 256 bytes to create such program. This is the macro:

Code:

.macro   savebyte val
   LDA #val
   STA $800,x
   INX
   .byte 3
.endmacro   

LDA #val is two bytes execute in two clock cycles so no need for dummy data; STA $800,x is 3-byte instruction that executes in 5 clocks so it does two dummy operations BUT the operations are in $800-$8FF range which is RAM area, so no dummy data needed in the instruction stream. INX is one byte but executes in two clocks, so it needs a dummy data which is $3.

The program after reset vector is LDX #0 to initialize regX (2-byte instruction executed in 2 clocks, no dummy operation), then a series of macro to create a program in RAM, followed by enough $3 illegal instructions to the last 3 bytes of the 256-byte FIFO which is JMP $800 to execute the program created in RAM.

The program created in RAM is a simple serial reader. It checks for serial receive data ready and write the incoming serial data to RAM start from $900. After 256 bytes of data is received, it jumps into $900 to execute.

The 256-byte serial data is an Intel Hex loader that loads a monitor and jumps into it. So this is a 4-stage boot process:
Stage 1, executes data from CF's master boot record to create a serial reader in RAM;
Stage 2, serial reader reads in 256-byte Intel Hex loader from the serial port;
Stage 3, Intel Hex loader reads in a monitor into memory
Stage 4, monitor load application programs as needed.

The reason for all these stages is ease of test and development. Later I'll shorten the process so Stage 1 creates a CF reader that reads dedicated sectors of data from CF disk into RAM and executes it.

This is the listing of the program in MBR.

Code:

00B300  1               ;This is the opcode stream for master boot record
00B300  1               ; it will be executed as stream of opcode for 65c02
00B300  1  EA              NOP         ;reset vector plus extra padding
00B301  1  EA              NOP
00B302  1  EA              NOP
00B303  1  EA              NOP
00B304  1  EA              NOP
00B305  1  03              .byte 3         ;illegal instruction executed in 1 cycle
00B306  1                           ;for synchronization purpose
00B306  1  A2 00           LDX #0
00B308  1  A9 A2 9D 00     savebyte $a2      ;LDX #0
00B30C  1  08 E8 03     
00B30F  1  A9 00 9D 00     savebyte $0
00B313  1  08 E8 03     
00B316  1  A9 E8 9D 00     savebyte $e8      ;add a delay loop
00B31A  1  08 E8 03     
00B31D  1  A9 D0 9D 00     savebyte $d0
00B321  1  08 E8 03     
00B324  1  A9 FD 9D 00     savebyte $fd
00B328  1  08 E8 03     
00B32B  1  A9 AD 9D 00     savebyte $ad      ;LDA SerStat($8000)
00B32F  1  08 E8 03     
00B332  1  A9 00 9D 00     savebyte $00
00B336  1  08 E8 03     
00B339  1  A9 80 9D 00     savebyte $80
00B33D  1  08 E8 03     
00B340  1  A9 29 9D 00     savebyte $29
00B344  1  08 E8 03     
00B347  1  A9 01 9D 00     savebyte $01
00B34B  1  08 E8 03     
00B34E  1  A9 F0 9D 00     savebyte $f0      ;BEQ xxx
00B352  1  08 E8 03     
00B355  1  A9 F9 9D 00     savebyte $f9
00B359  1  08 E8 03     
00B35C  1  A9 AD 9D 00     savebyte $ad      ;LDA SerData ($8001)
00B360  1  08 E8 03     
00B363  1  A9 01 9D 00     savebyte $01
00B367  1  08 E8 03     
00B36A  1  A9 80 9D 00     savebyte $80
00B36E  1  08 E8 03     
00B371  1  A9 9D 9D 00     savebyte $9d      ;STA $900,x
00B375  1  08 E8 03     
00B378  1  A9 00 9D 00     savebyte $0
00B37C  1  08 E8 03     
00B37F  1  A9 09 9D 00     savebyte $9
00B383  1  08 E8 03     
00B386  1  A9 E8 9D 00     savebyte $e8      ;INX
00B38A  1  08 E8 03     
00B38D  1  A9 D0 9D 00     savebyte $d0      ;BNE xxx
00B391  1  08 E8 03     
00B394  1  A9 F0 9D 00     savebyte $f0
00B398  1  08 E8 03     
00B39B  1  A9 4C 9D 00     savebyte $4c      ;JMP $900
00B39F  1  08 E8 03     
00B3A2  1  A9 00 9D 00     savebyte $0
00B3A6  1  08 E8 03     
00B3A9  1  A9 09 9D 00     savebyte $9
00B3AD  1  08 E8 03     
00B3B0  1  03 03 03 03     .res $4d,3      ;pad with illegal instruction that execute in 1 cycle
00B3B4  1  03 03 03 03  
00B3B8  1  03 03 03 03  
00B3FD  1                           ; until last 3 bytes of 256-byte page
00B3FD  1  4C 00 08        JMP $800
00B400  1               ;program above is executed as it streams out of CF data port
00B400  1               ;****************************** end of FT245 bootstrap ********************
00B400  1               ;   .org $800
00B400  1               ;this is the first stage loader, loading 256 bytes of following data into 0x900
00B400  1               ; then jump into 0x900
00B400  1               ;00  1  A2 00      LDX #0
00B400  1               ;02  1      delayx:
00B400  1               ;02  1  E8      INX         ;delay a bit for nDASP to negate
00B400  1               ;03  1  D0 FD      BNE delayx
00B400  1               ;05  1      xxx:
00B400  1               ;05  1  AD 00 80   LDA SerStat      ;chk serial receive ready flag
00B400  1               ;08  1  29 01      AND #1
00B400  1               ;0A  1  F0 F9      BEQ xxx
00B400  1               ;0C  1  AD 01 80   LDA SerData
00B400  1               ;0F  1  9D 00 09   STA $900,x
00B400  1               ;12  1  E8      INX
00B400  1               ;13  1  D0 F0      BNE xxx
00B400  1               ;15  1  4C 00 09   JMP $900

Top

plasmo

Post subject: Re: CRC65, A frugal 6502 SBC

Posted: Tue Nov 14, 2023 2:05 am

Joined: Fri Dec 21, 2018 1:05 am
Posts: 1119
Location: Albuquerque NM USA

CF blind boot implemented in CPLD is working well . I used another CRC65 to write the blind boot code to master boot record of a CF disk, then transfer the disk to the modified CRC65 with blind boot CPLD design. I can then bootstrap from the CF, load the Intel Hex loader followed by loading and running of the monitor program.

Now I'm ready to port the CPLD schematic to a TTL logic version. Attached is the schematic of a 6502 computer bootstrapped via CF disk as implemented in TTL logic. It takes 8 TTL chips and I'm not happy with it. I have ordered some GAL22V10; I'm going to learn WinCUPL (against my better judgement) and put these logic in a GAL22V10.
Bill

Attachments:

CFBoot_TTL_scm.pdf [38.36 KiB]
Downloaded 62 times

Top

gfoot

Post subject: Re: CRC65, A frugal 6502 SBC

Posted: Tue Nov 14, 2023 12:51 pm

Joined: Fri Jul 09, 2021 10:12 pm
Posts: 741

plasmo wrote:

If you can make your macro be something like this instead, then I think it would be smaller and need less initialisation:

Code:

.macro   savebyte val,addr
   LDA #val
   STA addr
.endmacro   

That's 5 bytes of CF per byte written (down from 7), or 4 if you write them to page zero instead, and there's no longer any need to initialise X on startup.

I was originally going to suggest using the stack (i.e. PHA) but that wouldn't save anything, it would still be 4 bytes per byte written, due to a dummy cycle, and would require some initialisation code, so I think the two-argument macro is better if it is supported and if it's OK to put this stage 2 code in page zero.

You mentioned that later you'd make the stage 2 code load sectors from CF disk - but personally I'd consider keeping an extra stepping-stone between the two in there, a bit like in Dr Jeffyl's system. The stage 2 code is quite inefficient to load, requiring at least 4 bytes per byte of code, but it can be efficient to run - all it needs to do is stream more bytes from the memory-mapped CF system to another area of memory, and chain to the result. For example, something as simple as this:

Code:

    ldy #0
loop:
    lda $8000
    sta $800,y
    iny
    bne loop
    jmp $800

That's 14 instructions, costing 4 bytes each to load from CF (if we load them to page zero), so 56 bytes, so the CF sector has about 440 bytes remaining, subtracting a few to cover other startup overheads. So this block of stage 2 code can stream the next 256 of these at $800, and then the code at $800 can stream the next 200 or so to $900, and now you have room for maybe 430 bytes of next-stage loader code - you can easily fit your serial-vs-CF autodetection at that point, as well as rich support for locating and loading the next stage from CF. Probably not quite enough for full filesystem support, unfortunately, as it would be great to be able to read the next stage from a FAT32 file rather than a raw sector.

I also may have misunderstood as you mentioned a 256-byte limit a few times - if CF sectors are only 256 bytes then I think this extra stage is all the more valuable, and you can make the above loop even smaller, maybe 10 instructions, if you let it load its target data into page zero as well. Then you have over 200 bytes left in the sector to store useful stage 3 loader code - the combined serial/CF bootstrapper for example.

Top

Page 9 of 10

[ 138 posts ]

Go to page Previous 1 ... 6, 7, 8, 9, 10 Next

Board index » 6502.org Users Forum » SBC- Series Projects

All times are UTC

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum