Quote from: Hydrophilic on March 14, 2011, 09:04 PM
Wow, I am glad it works on PAL systems.  Thanks for the report abraXxl.

Quote from: abraXxl
Hydrophilic: your implementation and my port has a problem if a datasette is connected to C64/C128@C64 mode. It simply hangs like the 1581 in the same scenario.

First time I've heard of anything like that.  I never owned a 1581, and haven't seen a datasette in years (me and my friends are still wondering what happened to the one we had years ago...).  I was only able to test that it works with 1571(s) attached (in 1571 and/or 1541 mode).

If anybody knows more about the C64 / 1581 bug, then it might be possible (from that info) to fix the firmware...

You assume while procession ATN and after you have sent the fast serial impulse, that if SRQ is low, the master C128 is able to do the fast serial protocol.
In C64 mode or on a real C64 SRQ is connected with the FLAG line on the datasette port. There some datasette models out there that pull FLAG down and so SRQ if the cassete motor is off.
There are also many hardware implementations out there that have SRQ not connected, so the SRQ pin is floating with no well defined input.

AFAIK The correct way is to wait for eight SRQ pulses. If you have received this indicator for the fast serial protocol from master, then and only then the sd2iec should send the eight SRQ pulses and only then wait for SRQ low.

Quote from: Hydrophilic on March 14, 2011, 09:04 PM
I guess I can take a look and see if there is some obvious problem... BTW, I have no idea what HEAD is... can somebody explain?

HEAD is the last checked in revision of code from a git repository. eg. if you simple type git clone http://www.sd2iec.de/sd2iec.git you get HEAD.
git pull and git diff are also handy

Quote from: Hydrophilic on March 14, 2011, 09:04 PM
I don't understand the UART dump... but I do know I had problems like you described at one point, and it was a similar problem.  Whenever there is a "disk change", either by insert new memory card, or "disk swap" button, or "CD" into disk image, then the firmware is coded to act like a 1571 and set "disk ID mismatch" until a BCIS "log in" occurs.

The "log in" can be with BCIS command "Inquire Disk" or "Query Status" as I recall... I don't have the code in front of me to tell you which U0 commands these are (I'm thinking code $0c is one).

Anyway, I had the problem described, where you get "booting cp/m plus" - "read error - hit return to retry".  This was fixed (for me) by changing firmware to clear the "disk change" when either BCIS command described above was sent.  So I could do this...

OPEN 1,10,15: REM uIEC default unit 10
PRINT#1,"CD:MYSOSSYS.D71": REM attach CP/M disk image
PRINT#1,"U0>"CHR$( 8 ): REM set uIEC to unit 8
CLOSE 1
BOOT

Umm... maybe I attached the disk image after changing the device number, but I don't think it would matter.  Anyway, CP/M worked for me, so I don't know the problem.... as I recall, the CP/M boot process will send the BCIS $0c command before any read sector commands, and it will also send it again after CP/M system is loaded but just before the A> prompt appears (I'm guessing this is just before CCP.COM is loaded).  Also the BCIS $0c command has high bit flags, and as I recall the actuall code sent is $4c (i.e., $55 $30 $4C $00).

You're right $55,$30,$4c,$00 (INQUIRE STAUTS) is sent and the following reads ($55 $30 $00 $01 $00 $01) seem to fail .
I have no idea why.

For an good char rom replacement you need for US to DE. You need an 8KB ROM subtitute. 0000-0fff 4Kb std cbm charrset. 1000-1fff 4Kb German charset.
Attention: The layout of U24 in a C128 single is an 2364, so you need an pinout adapter, as mentioned before.

The kernal should reside in U35, just exchange it with a fitting kernal.
In case you want Jjiffydos with an German editor. It should be possible, but you have to do it yourself. I haven't found any information how exactly this could be done. The German editor has some cross jumps accross the 4kb range C000-Cfff i don't exactly understand.

It is not neccessary to replace keyboard. This is only a cosmetic change, for the key lables.

Yes, this is possible.

The character rom is seperate, but on the old C128 single and the C128D (not cost reduced) you need an adapter for the ROM. Because it has another pinout. (2364 pinout)

The editor is in the kernal rom. Just exchange the kernal rom.

short bug report:
Hydrophilic: your implementation and my port has a problem if a datasette is connected to C64/C128@C64 mode. It simply hangs like the 1581 in the same scenario.

I adopted the your fast serial patch to current HEAD in Unseen's git repository.
Patch attached.
It still fits in Atmega 644  But I tested on Atmega 1284

The fast load in C128 mode works here C128/PAL. I tested with Risen from the Oblivion VDC v2 (227 blocks). It loads in ca 7.9 seconds wow.
But CP/M doesn't work. CP/M is stuck in boot screen "booting cp/m plus" - "read error - hit return to retry" "del to enter c128 mode"

For recving a byte via fast IEC i added a debug statement uart_putc('F'); to know if bytes are really transfered via your routine. It works.

Here the serial debug for booting cpm.d71
LFFFFFFFFFFFFFFFEA3f
0000| 43 44 3a 43 50 4d 2e 46 41 53 54 2e 44 37 31 0d |CD:CPM.FAST.D71.|
A28
Aef
A3f
A28
Af0
LEFA3f
0000| 24                                              |$               |
A48
A60
TVA5f
A48
A60
T+A48
A60
TA5f
A28
Ae0
A3f
A28
Aff
LEFA3f
0000| 49                                              |I               |
A28
Afd
LEFA3f
0000| 23                                              |#               |
A28
A6f
LFFFFFFFFFFFFEA3f
0000| 55 31 3a 31 33 20 30 20 30 31 20 30 30          |U1:13 0 01 00   |
A48
A6d
TVA5f
A28
Aed
A3f
A28
A6f
LFEA3f
0000| 55 49                                           |UI              |
A28
Aff
LFFFFEA3f
0000| 55 30 3e 56 31                                  |U0>V1           |
A28
Aef
A3f
A28
Aff
LFFFEA3f
0000| 55 30 4c 00                                     |U0L.            |
A28
A6f
LFFFFFEA3f
0000| 55 30 00 01 00 01                               |U0....          |
A28
A6f
LFFFFFEA3f
0000| 55 30 00 01 00 01                               |U0....          |
A28
A6f
LFFFFFEA3f
0000| 55 30 00 01 00 01                               |U0....          |
A28

This implies to me that something goes wrong in "U0"+chr$(00) command: burst read.
@hydropholic:
If you have time, please check out current git and test my patch, perhaps you see what I have missed.

Thank you for your work.  I love it, too.

@brain: Concerning the Bootrom code.

Quote from: brain on March 02, 2011, 04:31 AM
and ensure their application worked.  I'm not convinced folks need that level of flexibility in a boot record.  It's typically used once per computing session.

You're right. Yes, a hard coded BOOT.BIN would be sufficent for most users.
I do same for the ROM images with XR:FLOPPY.ROM written in my MMC2IEC devices. This file searched firstly in current directory by the firmware and then in root directory. In my Geos work directories is placed a FAKEHD.ROM, to mimic a CMD-HD drive. So I am not using this flexibility of the XR-Command.

AFAIK none of the three 4 player adapters I know can be auto detected. You need user interaction like e.g. press 3rd joystick fire or press 4th joystick fire.

Quote from: brain on February 28, 2011, 11:33 AM
The firmware, at one point a year or so back, would still fit in the MMC2IEC hardware, but no longer.

Quote from: brain on February 28, 2011, 12:01 PM
The larger issue with this added firmware support if the firmware image size.  Currently, the sd2iec firmware is approaching 60K, and only uIEC (with 124K of firmware space) can hold larger firmware images.

If you replace the AtMega644 with the pin compatible Atmega1284 in the LarsP/MMC2IEC this not true anymore. It has 128kb flash memory, too.

Quote from: brain on February 28, 2011, 11:33 AM
It is impossible to brick the uIEC by loading new firmware via the SD card :-)  Hack away!

The bootloader scans for files in rootfs with a specific size. For LarsP/MMC2IEC/Atmega644 the size is 61440 bytes and for uIEC/1281 and Larsp/1284 it is 126976 bytes. To ensure that the devices stays functional a specific hardware id is also encoded in the flash file, the version is also compared. The new to be flashed firmware version must be newer than the old.

Quote from: brain on February 28, 2011, 11:56 AM
Sadly, LarsP does not support the SRQ line, but maybe you can solder a wire to the correct pin and update the firmware defines to add support for the pin.

As far figured out by today, some people like PeterSieg/Diddl use pin PC3 for SRQ on the 328/644/1284 with LarsP layout.

Quote from: brain on February 28, 2011, 11:51 AM
If you're planning to implement the boot sector in sd2iec, please let me know.  It would be best to implement it two different ways.  When not in an image, it should load a boot.img file in the root directory, or something like that.

I like the way the XR: command works for rom images. So here my idea. The command XC: is free (e_X_tended commands _C_128 bootsector). XC:filename. If sd2iec firmware is in native filesystem mode and track,sector 1,0 is requested the first 256 byte block of the file is sent. The file is firstly searched in current directory and then in the root filesystem. This way you could also implement longer sector chains to be read as bootsector. Just send the following 256 byte block of the file are send.

:wq

I understand your concerns. What is the problem with the fast serial handshake? My understandig, I got from here and here, both communiation partners try to transfer a byte via SRQ/ATN. If the transfer was successful, a flag is set, that indicates that both are capable for fast transfer mode. You also want to have a look in the source for the XS1541, a XU/XUM1541-like device that runs on the LarsP-Layout, too. It can do fast serial transfer with 1571/81 drives. Perhaps it helps.

Well, nice to see some progress here

Are the patches avaiable for public testing and does Unseen Pull them into his git-Repository? Are in contact with him, so that patches don't get lost.

What is the AVR pin you used for SRQ.
I have 3 of these PCBs - called LarsP layout with Atmega 644/1284 running SD2IEC Firmware. I would happily test and adopt this to LarsP layout.

Of course you need the current sd2iec version, currently 0.10.1.

Have a look at the Readme regarding the XW und XR commands.
README

...
XR:name  Set the file used for file-based M-R emulation.
XR       Disable file-based M-R emulation.
           See "M-R, M-W, M-E" below. This setting can be
           permanently saved in the EEPROM using XW.

XW       Store configuration to EEPROM
            This commands stores the current configuration in the EEPROM.
            It will automatically be read when the AVR is reset, so
            any changes you made will persist even after turning off
            the hardware.
...

Put the fake rom file you are using in the directory where your DNP/D41/D81 images are.

I have not yet used the SD2IEC as a boot drive.

1. You have to mount a DNP-Image (Native CMD HD Partition) before you boot to Wheels.
2. It works best if you use the XR: command from current 0.10.1 firmware version with the fake roms from http://www.sd2iec.de/fakeroms.zip. This way the sd2iec-FW mimics a CMD HD when the Wheels Loader is detecting the device.

It would be interessting to know for what CBM machine the Datel Kernal Switcher is designed for.
If its a C64 I kernal switch, it usually switches A13 of the kernal ROM. If it's designed for the C64 II (ASSY 250469), it should switch A14. For selecitng two 32k EPROM Banks in U36 it should switch A15.

Hey!

Nice to see some work for the fast serial protocol.
Have you contacted with Unseen@Forum64 one of the devs behind the sd2iec firmware? Perhaps he can give you some advice.

I have contributed the Nippon fastloader subroutines with an also simple loop. For the burst protocol I guess a better integration into the sd2iec architecture is needed and far above my knowlegde about the sd2iec sources.

It is often handy to have an serial console cables (USB-RS323) ready for debugging.
What strange effects can happen in WinDos specific build environments I can't tell, my build environment is Ubuntu Lucid, where
"apt-get install avr-gcc avrdude make gawk vim" installed all neccesary for me.

Well that means in 79.192.0.0/10 exists 2^22-2 possible addresses as in possible users. That means by taking the 22484 as the current ratio of bots vs clean PCs, that you lock out ~4 milion users because of 0.5% of bots in this net.

The german telekom also locks accounts down, if they are used as bots. Do  know how fast normal ISPs (geman, international and so american) detect an lock out known bot PCs? The bots can run usually 1-2 days until the ISP do some sort of intervention. I would suggest again that you would use more advanced technics to lock out spammers. Some very neat technics are logging exhaust abuse, charackterized by some the following criteria: clients with no referer, freuqent accesses by on IP to submit/post pages, using some dns blacklists ...
Write that in to a database and generate .htaccess or packet filter rules to lock out theses clients for some time (eg 24h).

Actually I believe that only a small percentage of the mentioned 22484 clients are still bots. Okay there might be new in this range, but this you an me can't prove because you locked them _all_ out.

:wq

Hi,

as a german reader of this board I am also affected by this _huge_ (T-Kom 93.192.0.0/10) IP range, luckily there are other ways for me to access this BBS.

The blocked ip range contains the major 4 ISPs in Germany with more than 15 million customers. Under that mass of common internet usersm, you may find many bots. I guess many more bots than retro/commodore interessted users - when this holds for other ISPs you can block everything except than 127.0.0.1 ;)

I don't know where the problems exists here with spammers. It migth be more helpful to extend the anti-spam features of the board other than going to the case when only a /32 network can access the board.

I needed about three weeks to firgure out what was the case. I thougt you were having technical difficulties. I would like to see this fixed, I don't like surfing from work for my private use.

regards from Germany

The internal function rom is mapped to bank 4, the external is mapped to bank 8, both at 8000-ffff.
There is an start sequence similar to the CBM80 sequence at c64.

These startup sequences have to placed at $48000, $4c000, $88000 an $8c000.
This code has the following layout:

0/1/2/3 - unused - (AFAIK)
4 -  00 - ROM entry point is not called -
     01 - entry point is called before the kernal initialized completly
     02-ff - entry point is called after kernal and basic is initialized, shortly before disk boot up
5/6 - vector function entry point
7/8/9 - "CBM"


The code the vector at $5/6 is executed in bank 4 or 8. Regard that at $d000 IO is located, and that in every bank at $ff00 to $ff04 the MMU-CR registers are placed.

At the end some example code I use to call C64 programs from the function rom.

; vim:ts=4:ft=asm:fdm=marker:fmr={,}

; c128 function start code {
; function rom start address
.byt $00, $80
*=$8000
func_rom_boot_code:

; C128 function rom stub
.byt $ea, $ea, $ea, $4c
.word func_rom_entry
.byt $02
; 00 - don't start
; 01 - start before kernal init
; 02 - start after kernal and basic init, shortly befor disk boot
.byt $43, $42, $4d
; }
; labels {
VIC = $d000
VIC_CLOCK = VIC + $30

C128_code_bank0_15 = $220

; changable entry point for own go64
C128_c64_entry_point_lo = C128_code_bank0_15 + go64_bank0_code_entry_len
C128_c64_entry_point_hi = C128_c64_entry_point_lo + 1

C128_MMU = $d500
C128_MMU_MCR = C128_MMU + 5
C128_MMU_CR = $ff00
; }

; code entry in bank 4/8
func_rom_entry:
; disable interrupts {
sei
; }

; go c64 {
jsr copy_go64_code
lda C128_c64_entry_point_lo
lda C128_c64_entry_point_hi
jmp C128_code_bank0_15
; }

; padding to 32k {
func_rom_boot_code_end:
#echo Free bytes function ROM
#print $ffff - func_rom_boot_code_end - 255
.dsb $ffff - func_rom_boot_code_end - 255, $ff
; }
above_mmu_codeblock: ;{
; 5 MMU registers are mirrored here
.byt "12345"

; go to fast/slow 1/2mhz {
slow:
lda #00
.byte $4c ; mask next opcode
fast:
lda #01
sta VIC_CLOCK
rts
;}

; enable IO {
enable_io:
lda C128_MMU_CR
and #%11111110
jmp disable_io_write
;}
; disable IO {
disable_io:
lda C128_MMU_CR
ora #%00000001
disable_io_write:
sta C128_MMU_CR
rts
;}

; copy go64 code to $C128_code_bank0 {
copy_go64_code:
;jsr enable_io
    ldy #go64_bank0_code_end-go64_bank0_code_start+1
go_64_cody_copy_loop:
lda go64_bank0_code_start-1,y
sta C128_code_bank0_15-1,y
dey
bne go_64_cody_copy_loop
rts
; }

; { bank0 ram code for go64
go64_bank0_code_start:
lda #0 ; bank 15
sta C128_MMU_CR
lda #$f7
sta C128_MMU_MCR
go64_bank0_code_entry_len = * - go64_bank0_code_start + 1 ; = #fce2
jmp $FCE2
go64_bank0_code_end:
; }

above_mmu_codeblock_end:

.dsb 251 - (above_mmu_codeblock_end - above_mmu_codeblock), $ff
#echo Free bytes in above MMU_BLOCK
#print  251 - (above_mmu_codeblock_end - above_mmu_codeblock)
; }
; ensure we have nmi and irq vectors pointing to meaningful routines for some incidents might happen {
; dummy IRQ and NMI routines
blank_irq_nmi:
irq_entry:
nmi_entry:
rti
; IRQ
.word blank_irq_nmi
; NMI
.word blank_irq_nmi
;}


Have a look at "Mapping the C128" page 519 and 597 for more info.