Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update build-firmware.yml #21

Merged
merged 1 commit into from Apr 27, 2022
Merged

Update build-firmware.yml #21

merged 1 commit into from Apr 27, 2022

Conversation

RaceSoft
Copy link
Contributor

No flip OLED and VFFS, turn on DEBUG

No flip OLED and VFFS, turn on DEBUG
@acemielektron
Copy link
Owner

Hi @RaceSoft , I see you have forked fddEMU, and changed the lines in build script. I will incorporate the changes you requested. But what I meant in blog comment was you can build your own fddEMU release in your fork. If you enable github actions in your fork of the repository and run build script, you can then find the resulting firmware files in your releases.

Copy link
Owner

@acemielektron acemielektron left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will add both flipped versions later.

@acemielektron acemielektron merged commit 6f8d858 into acemielektron:main Apr 27, 2022
@RaceSoft
Copy link
Contributor Author

RaceSoft commented Apr 27, 2022 via email

@acemielektron
Copy link
Owner

Hello again @RaceSoft it seems you haven't used actions yet. You can download this build resulting from your modification to build script.

@RaceSoft
Copy link
Contributor Author

RaceSoft commented Apr 27, 2022 via email

@acemielektron
Copy link
Owner

Hmm, I have thought about the write problem in the meantime, AVR (atmega328p/atmega32u4) can't switch from reading to writing and writing to reading immediately which a normal floppy drive certainly could. Current fddEMU waits a set time after sending every sector header to FDC and during this time checks if WRITE_ENABLE is asserted. If WRITE_ENABLE is asserted CPU switches to reading data from FDC, then write this data to sd-card, then waits till WRITE_ENABLE is released, then switch again to writing floppy sectors to FDC, which is the way writing to a floppy works normally from the perspective of a FDC (my reference FDC is ArduinoFDC). This set time (20 loops of check WRITE_ENABLE) works for 1.44MB images but as I don't have other systems -non-1.44MB floppy systems- I couldn't do tests on those systems, maybe they require a longer wait.
The alternative to waiting WRITE_ENABLE is connecting WRITE_ENABLE to an interrupt and doing task switching inside the interrupt, which is more complicated but elegant solution.
If your debugging results support waiting time is short theory we might try a longer wait time for low density floppy formats.

@RaceSoft
Copy link
Contributor Author

RaceSoft commented Apr 27, 2022 via email

@RaceSoft
Copy link
Contributor Author

RaceSoft commented Apr 28, 2022 via email

@acemielektron
Copy link
Owner

If debug is enabled fddEMU outputs written sectors to serial console. So if it is not printing received data to serial it is not capturing WRITE_DATA.
I have tried increasing the wait/check duration for DD disks. I hope this would resolve the issue. You may download and try the latest firmware.

@RaceSoft
Copy link
Contributor Author

RaceSoft commented Apr 29, 2022 via email

@acemielektron
Copy link
Owner

acemielektron commented Apr 29, 2022 via email

@RaceSoft
Copy link
Contributor Author

RaceSoft commented Apr 30, 2022 via email

@acemielektron
Copy link
Owner

Thank you for your comment. If possible can you describe the problem a little more.
After reset, reading drive A is still working but reading drive B fails ?
Or reading from drive B works but writing fails ?
Or fddEMU freeze ?
If you try loading a new image file to drive B then try reading, does it work?
If you are using debug enabled version what is shown on serial console ?

@RaceSoft
Copy link
Contributor Author

RaceSoft commented Apr 30, 2022 via email

@acemielektron
Copy link
Owner

Thank you for your detailed description.

  • Though I can't be sure why drive B doesn't work after reset. You said after loading a new image file to drive B it worked, this might be caused by changes drive B settings, so I have implemented a tighter control of bit rate and made DD default while initializing the drive e0c5ac8.
  • Sometimes it looks like write successful, sometimes fddEMU freeze. Hmm, It seems sometimes it catches the WRITE_GATE signal and freeze while waiting data from computer and sometimes it doesn't get the WRITE_GATE and continues pushing data to computer. I have increased wait for WRITE_GATE e0c5ac8 as you suggested, but freezing while receiving data from computer usually occurs due to insufficient pull up resistor at WRITE_DATA pin. Arduino has internal pull up resistor of ~ 30Kohm (if I remember correctly). Long floppy cable acts as parasitic capacitor smoothing the signal, causing signal to become unreadable by Arduino. A stronger/faster pull up (~ 1Kohm) supplied externally usually resolves this problem. Please first check if the pin D8 of Arduino nano is connected to pin 22(WRITE_DATA) of floppy cable, and floppy cable is not broken (check continuity) then check a sufficient external pull up resistor is connected to this signal.

Hi, i try describe the behavior of the system: 1) after switch on, i select images for disk A: and B: - different. System booted, reading from A: and B: working correctly. I can switching betwen both drives and read data from both drives (attached file OK.TXT) 2) when at this moment I make RESET of computer, system booted perfectly from disk A: (images in fddEMU not changed), but disk B: is not accessible - BDOS ERROR... (attached file ERROR.TXT) 3) same as 2), but before accessing to disk B: I change image in fddEMU, B: working perfectly. 4) writing still not working - either system look like the write was successful, but data not writed or I see message BDOS ERROR... on computer and fddEMU freeze - on OLED is visible active disk with text BUSY and blinking LED L (D13, SCK) on Arduino In attached files I marked point, when I changed drive from A: to B: on computer. And litte notes on end: while using serial interface for change images, I see text FS: and several unreadable characters program writes characters from variable wbuf - use hex format? Maybe to debug add information about active drive to log. And do not flickering with information about active disk on OLED display - it would be enough simulate flickering LED next to a floppy disk symbol or inversion only floppy disk symbol. Petr

@RaceSoft
Copy link
Contributor Author

RaceSoft commented May 1, 2022 via email

@acemielektron
Copy link
Owner

I have looked at the photos. Really impressive. Is that a self made Floppy Drive Controller ? It really is a work of art. I guess CM609P 8824 is the floppy controller IC, though I couldn't find a datasheet for it. You have even built @ikonko 's pcb design by hand (he had those PCB's manufactured). I also do design and etch my PCB's myself, but my self made PCB's are not as clean and professional as yours (eg.: STM32F103C8T6_DEV_BOARD)
It seems despite our efforts, the after reset dis-function problem of drive B still persists. I wonder if there is any progress on writing to disk ? Today I tried booting a 720K DD ms-dos 5 floppy image then writing to it using e0c5ac8 fw. It booted without error, writing to disk image worked (I later checked the disk image on sd-card). But my test system is a Pentium-II with a HD capable controller. Maybe that's why I can't reproduce the error.
With your permission I would like to move our later correspondence to a discussion in github (currently it's in pull request where most people won't see). I would like to share your photos and details of our progress there. It would be very nice if you could also post details of your system there. Please let me know your decision.
Thanks again

Hello, on addres: https://drive.google.com/drive/folders/1r_QGt38Jp-3HE1OQFfGOURuA_uyQlkj0?usp=sharing [https://drive.google.com/drive/folders/1r_QGt38Jp-3HE1OQFfGOURuA_uyQlkj0?usp=sharing] i have some system photos.Petr</pull/21/c1114148132 @github .com>

@RaceSoft
Copy link
Contributor Author

RaceSoft commented May 1, 2022 via email

@RaceSoft RaceSoft deleted the patch-1 branch May 1, 2022 21:36
@acemielektron
Copy link
Owner

Thank you @RaceSoft I have started a new discussion thread on fddEMU discussions. If you post your later comments there, I think it would become more accessible to people interested in fddEMU. I really enjoyed your pictures of fddEMU booting the Consul C2717. And your homemade fddEMU PCB is also great, looks really professional. If you want you can add pictures to your posts by dragging them over to comment.
P.S.: I scaled down your pictures a bit (~ 1/4) before posting for faster loading, I hope this is all right with you.

@RaceSoft
Copy link
Contributor Author

RaceSoft commented May 2, 2022 via email

@RaceSoft
Copy link
Contributor Author

RaceSoft commented May 3, 2022 via email

@acemielektron
Copy link
Owner

Thanks, that is what should happen

@RaceSoft
Copy link
Contributor Author

RaceSoft commented May 5, 2022 via email

@acemielektron
Copy link
Owner

Hello Petr,
Thank you for the debug logs. After your previous comments I have been working on fddEMU core. I have mostly rewritten avrFlux, added error handling and crc-check to reads, so -hopefully- it should no longer freeze and won't write corrupted data to disk. As I have written in README.md fddEMU is a hack, but thanks to you and @ikonko now it is less hack, more a proper floppy drive emulator (By hack I mean it reads sector data from sd-card before sending the data to FDC so it doesn't stream data continuously). I am attaching a compiled version of current test feature commit 1a55561 to this post that I hope you can test.
fddEMU-1a55561.zip

@RaceSoft
Copy link
Contributor Author

RaceSoft commented May 5, 2022 via email

@acemielektron
Copy link
Owner

Thank you for the fast response. I will recheck as well.

@acemielektron
Copy link
Owner

Ok, here comes 4db7038
Tested on PII system running win98, read/write crc check working.
I hope it also works on Consul C2717 "Zbrojovacek".
fddEMU-4db7038.zip

@acemielektron
Copy link
Owner

here is the promised fddemu.zip I have reduced gap2 bytes 21 to 18. If Consul C2717 is asserting WRITE_GATE early rather than late this should catch it. Otherwise increased wait for WRITE_GATE should have solved the problem. I am guessing that Consul C2717 sometimes asserting WRITE_GATE early and sometimes late on a physical floppy gap2(post header - pre sector) and gap3(post sector) should account for this behavior. Let me know if I'm on the right track.

@acemielektron
Copy link
Owner

Sorry, after reading your next message and looking at logs I understood what is happening with drive B.
Because drive change is happening at interrupt, emulation loop is not checking which drive it is currently emulating. This doesn't happen with pc, so I didn't see this before. Consul C2717 or rather floppy drive controller is not releasing drive select lines. So even you change the select line same drive is running, track and sector stays the same. I patched this, but not tested yet. Here is the compiled fddemu.zip.

And thank you, this is great progress.

@acemielektron
Copy link
Owner

Here are the changes c1a25ed

@RaceSoft
Copy link
Contributor Author

RaceSoft commented May 8, 2022 via email

@acemielektron
Copy link
Owner

acemielektron commented May 8, 2022 via email

@RaceSoft
Copy link
Contributor Author

RaceSoft commented May 8, 2022 via email

@acemielektron
Copy link
Owner

Thank you very much.
I hope that together we would make fddEMU a better emulator many people can use.
I have finished modifications we talked about. I will look into releasing signal lines when no select line is asserted, then test it. After the test I plan to merge the resulting code to main, so the firmware would be automatically built. I will message you then. And thank you for your patience as well.

I tested last FW, but nothing change in result - drive B: is still remember last used track and not reset this after RECALIBRATE. Tomorrow I make record from logical analyzer. Sorry today I do not have power make some next measuring. I had relatively hard work in our forrest and have it is enough. I will write to you tomorrow. IMHO, if no signal / DSx is active, fddEMU should put ALL output signals in an inactive state - ie in log.1 - stop output /RDATA, /INDEX, /TRK00, .... In the previous version it this was not the case and when active / DS1 the status for active / DS0 was actually read. I do not know, what the signals look like now. Many thank you for your patience. Petr

@acemielektron
Copy link
Owner

Hello @RaceSoft
Sorry for the wait, I have made too many changes at once and things broke, so I had to backtrack.
I have merged changes so latest release is now 52dee81.
There are still many things to fix and improve. But for now I am focusing on:

  • writes on Consul C2717
  • track/sector persisting from drive A to B

I tested last FW, but nothing change in result - drive B: is still remember last used track and not reset this after RECALIBRATE. Tomorrow I make record from logical analyzer. Sorry today I do not have power make some next measuring. I had relatively hard work in our forrest and have it is enough. I will write to you tomorrow.
IMHO, if no signal / DSx is active, fddEMU should put ALL output signals in an inactive state - ie in log.1 - stop output /RDATA, /INDEX, /TRK00, .... In the previous version it this was not the case and when active / DS1 the status for active / DS0 was actually read. I do not know, what the signals look like now.

@RaceSoft
Copy link
Contributor Author

RaceSoft commented May 10, 2022 via email

@acemielektron
Copy link
Owner

acemielektron commented May 10, 2022 via email

@RaceSoft
Copy link
Contributor Author

RaceSoft commented May 10, 2022 via email

@RaceSoft
Copy link
Contributor Author

RaceSoft commented May 10, 2022 via email

@acemielektron
Copy link
Owner

That's not happening on my computer. Is there a problem with github compiled fddEMU? I should test it. Here is my locally compiled version fddEMU.zip

@RaceSoft
Copy link
Contributor Author

RaceSoft commented May 11, 2022 via email

@acemielektron
Copy link
Owner

acemielektron commented May 11, 2022 via email

@RaceSoft
Copy link
Contributor Author

RaceSoft commented May 15, 2022 via email

@acemielektron
Copy link
Owner

Thank you,
I am trying to implement task switching which may take a while. While I am at it I will try to remove complexity added by i2c and petitfs. I will inform you (hopefully) when I finished.
Sorry for your power supply, I hope it doesn't break again.

Hello, I finally back. First I had must repaired power supply again - modern components doesn't last that long as the old, still communist ones :-).
I try Your last version fddEMU with the same result: BDOS ERR ON A: BAD SECTOR (photo on Google disk). My mistake in previous post, sorry. I recorded log from LA - red mark show, where error pop up. It can be seen in log that signals from fddEMU are already responding correctly to the / DSx inputs. The display then show "BUSY" (only plain text), but none /DSx do not active. I try flash previous version (from 8. may), I used same SD card with same images, and system booted normaly and B: working with described error.
Many thanks for Your patience.
Petr

@RaceSoft
Copy link
Contributor Author

RaceSoft commented May 30, 2022 via email

@acemielektron
Copy link
Owner

Sorry for the late answer, and thank you. Congratulations on your success with HxC. Lately I have a lack of spare time due to increased work load. I haven't been able to complete the changes to fddEMU yet.
I just wonder if eliminating post-data gap would make current fddEMU usable for SM609R again. It would be a simple change to try.

@RaceSoft
Copy link
Contributor Author

RaceSoft commented May 31, 2022 via email

@acemielektron
Copy link
Owner

acemielektron commented Oct 11, 2022 via email

@RaceSoft
Copy link
Contributor Author

RaceSoft commented Oct 11, 2022 via email

@RaceSoft
Copy link
Contributor Author

RaceSoft commented Oct 11, 2022 via email

@RaceSoft
Copy link
Contributor Author

RaceSoft commented Oct 11, 2022 via email

@RaceSoft
Copy link
Contributor Author

RaceSoft commented Oct 11, 2022 via email

@RaceSoft
Copy link
Contributor Author

RaceSoft commented Oct 11, 2022 via email

@acemielektron
Copy link
Owner

acemielektron commented Oct 11, 2022 via email

@RaceSoft
Copy link
Contributor Author

RaceSoft commented Oct 11, 2022 via email

@RaceSoft
Copy link
Contributor Author

RaceSoft commented Oct 11, 2022 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants