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

RTC possible? #2

Open
snhirsch opened this issue Aug 18, 2020 · 12 comments
Open

RTC possible? #2

snhirsch opened this issue Aug 18, 2020 · 12 comments

Comments

@snhirsch
Copy link
Contributor

I use Z-System (NZCOM) with z80pack on my Linux machine and have come to rely on the z80pack RTC for timestamping support. Unfortunately, the pano_z80 BIOS doesn't seem to have implemented it and I get cascades of error messages about port access. Does the Panologic G1 hardware have anything that could be leveraged for this purpose? Maybe a timer-based clock that one sets on boot?

I'm also seeing Z80HALT and lockups from time to time. Is there any trace or debug functionality present that could be used to chase this down?

@skiphansen
Copy link
Owner

I'm afraid there isn't any hardware support for an RTC of any kind. If someone gets the Ethernet port up we could use NTP, but no one is working on it that I am aware of. A timer-based clock that one sets on boot is certainly doable. I don't know how accurate the clock is, but I would get it's fine for a day or two...

There isn't any debug capability currently.

@snhirsch
Copy link
Contributor Author

snhirsch commented Sep 1, 2020

Hi, Skip. Did you have any luck implementing an interrupt-driven clock? If you can define the hardware, I may be able to help with the RISCV coding. At this point, Verilog is like Greek to me :-).

@skiphansen
Copy link
Owner

No, I've been trying to fix the first USB port which is proving to be challenging.

You might be able to do it without hardware, the RISCV has a built in counter of the number of cycles since power on that you could use for a time reference. time() returns the number of cycles since power up, at 25 Mhz it wraps every 171 seconds.

All of the Z80's I/O that isn't handled are already in RTL is redirected to the RISCV (see

void HandleIoIn(uint8_t IoPort)
)

Have fun! I promise won't collide with you time time.

@snhirsch
Copy link
Contributor Author

snhirsch commented Sep 1, 2020

Ah, ok. So the idea would be to check it on each iteration of the main I/O loop, correct?

@skiphansen
Copy link
Owner

Yup, that's the idea. Read the current number of cycles, subtract the number of cycles last time it was read, add the delta to an accumulated time. When the z80 reads the clock convert to the appropriate format.

@snhirsch
Copy link
Contributor Author

snhirsch commented Sep 1, 2020

Great. Handling counter wraparound is simple, given that we're unlikely to have an I/O operation taking more than 171 seconds. Let me see what I can do.

@snhirsch
Copy link
Contributor Author

snhirsch commented Sep 11, 2020

I have the timekeeping logic nominally working, but it turns out the main loop blocks on HandleIoIn() so it's possible to lose track of counter wraparound during long idle periods. Is this expected? I moved the code into the IdlePoll() function and things now work properly.

@skiphansen
Copy link
Owner

skiphansen commented Sep 11, 2020

Good point, I didn't think about that. Moving your code into IdlePoll() and should be good. HandleIoIn() should be calling IdlePoll() while waiting for console input.

The BIOS is a bit of an odd interface since it was written for the z80pack simulator. The way I read the code reading the console port blocks until keyboard data available.

Send me a pull request when you are happy with the changes and I'll merge it.

@snhirsch
Copy link
Contributor Author

Ran into a problem: Since the firmware does not include libc there are no date parsing functions available. Is there a way to selectively link from the full libc without bloating things up? I searched for open source date functions and cannot find anything usable. Neither uClibc or MUSL are available for RISCV32.

@skiphansen
Copy link
Owner

So gmtime() /localtime() is what you need? If so the it looks like you could probably swipe gmtime_r.c from the library sources and just compile it along with the other sources. It doesn't look like it's dependent on other functions and looks like it should be fairly easy to get to compile (famous last words).

skip@Dell-7040:~/riscv-gnu-toolchain-rv32i$ find . -name gmtime_r.c
./riscv-newlib/newlib/libc/time/gmtime_r.c

There's plenty of RAM for the RISCV, the problem is the somewhat limited flash space. The basic program skeleton dates back to when everything needed to fit into the FPGA's on chip RAM before the DDR2 RAM was brought up.

@snhirsch
Copy link
Contributor Author

Actually, I need strptime(), which has some nastier dependencies. I found a source file in 'newlib' and am in the midst of hacking it to suit. Sort of a pain, but I should be able to do it.

@snhirsch
Copy link
Contributor Author

Update: I have all the date handling functions coded and working. Currently cooking up a line-oriented input routine for RISCV code. Should have this working by tomorrow.

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

No branches or pull requests

2 participants