Jump to content
santosp

eclaire XL P.C.B. aka "Atari on FPGA project"

Recommended Posts

Mark calls it  Core...  I call it firmware.  At the end we meaning the same thing.;-) 

Why dont try some steady previous version and stay there?

Share this post


Link to post
Share on other sites
5 minutes ago, santosp said:

Mark calls it  Core...  I call it firmware.  At the end we meaning the same thing.;-) 

Why dont try some steady previous version and stay there?

Firmware is software in ROM that has to be executed by some sort of CPU, an FPGA has no CPU

 

Share this post


Link to post
Share on other sites
1 hour ago, JamesD said:

Firmware is software in ROM that has to be executed by some sort of CPU, an FPGA has no CPU

 

This was not the point of the question of AA member, but thanks for the explanation. 
The same explanation must given in many web sites which refered to firmware on fpga.  For example these are some and if someone take a look will find enough more.

 

https://intellijel.com/support/fpga/

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.819.2639&rep=rep1&type=pdf

 

Also, a very usefull controversy is shown below...  

https://groups.google.com/forum/#!topic/comp.arch.fpga/p4C2LwHoUoE

 

  • Like 1

Share this post


Link to post
Share on other sites
14 hours ago, santosp said:

This was not the point of the question of AA member, but thanks for the explanation. 
The same explanation must given in many web sites which refered to firmware on fpga.  For example these are some and if someone take a look will find enough more.

 

https://intellijel.com/support/fpga/

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.819.2639&rep=rep1&type=pdf

 

Also, a very usefull controversy is shown below...  

https://groups.google.com/forum/#!topic/comp.arch.fpga/p4C2LwHoUoE

 

Bravo, you found other people that misused the term firmware!  That must mean you are correct!
I can find hundreds of examples where people refer to assembling assembly language as compiling, but that doesn't mean that's correct either.
Here is my linky:
https://opencores.org/

The term firmware was coined around 1967 when FPGAs weren't even a twinkle in an engineer's eye, and even the wiki calls firmware software... not that wiki can't be wrong (as I sit here and wait for someone to change the Wiki to say it includes FPGA cores as firmware). 
FWIW, firmware was hard wired in core memory at the time the phrase was coined.  :P

Frankly, I wouldn't have said anything if you hadn't gone to the trouble of pointing out how you called it firmware and Mark called it a core.
I think the poster that asked if he should update the firmware was talking about the ROM (he said he updated the core), so it's important to distinguish between the two to avoid confusion.
If you say a core update is needed, it's clear you need to update the FPGA, and if firmware is the ROM for the 6502, things are still clear if you say the firmware needs an update. 
If you say update the firmware but it means either... then what are you updating exactly?
 

Share this post


Link to post
Share on other sites
13 minutes ago, JamesD said:

Bravo, you found other people that misused the term firmware!  That must mean you are correct!
 

:?:?:?:?

  • Like 1

Share this post


Link to post
Share on other sites
18 hours ago, venom4728a said:

What is the latest Firmware and how do I find out what I have?

It is the basis for veeery long and intense discussions among AA members. 😈

 

Or if you want to skip the discussions: It's a different term for the same stuff. 😎

  • Like 1
  • Haha 1

Share this post


Link to post
Share on other sites
52 minutes ago, santosp said:

:?:?:?:?

Just because other people use it doesn't make you right

Share this post


Link to post
Share on other sites

ZPU firmware (c):

http://www.64kib.com/atarixlfpga_svn/trunk/atari_800xl/firmware_eclairexl/

Hardware description (vhdl/verilog):

http://www.64kib.com/atarixlfpga_svn/trunk/atari_800xl/common/a8core/

 

I compile both into a sof/pof/jic - which I call together the core. The jic additionally includes some other data that gets stored in the flash.

 

Anyway, call it as you wish, I don't want any fights. + Panos did a lot of work on this project, so please be nice to him!

 

  • Like 11

Share this post


Link to post
Share on other sites

just to change a subject... how's your investigation going foft?

is there any chance to revive sio interrupts? 

pleaaaase 🙏

  • Like 4

Share this post


Link to post
Share on other sites

I started to take a look tonight. I expect I’ll get somewhere this weekend. I need to check vs the data sheet. I found a bit todo in my HDL from 2013 - check this, interrupts not used much on A8:)

  • Like 1

Share this post


Link to post
Share on other sites
On 5/28/2020 at 11:32 AM, TheMontezuma said:

Do you observe any issues with v37 when pressing F9 (normal reset)?

I ran the eclair for about 5 or 6 hours today.  One time I forced to cycle power, it seemed like the RESET wasn't working.  I had placed an Boot without Basic atr image in D1: I Pressed Option(F8) and System RESET (F10). The system went to memory test screen.  I tried a few more time using (F8)+(F9) or (F10) still went to Memory test screen until I cycled power then everything worked normally again.  

The other Issue I was seeing before updating to V37 was software wouldn't recognize a disk change, but it did not happen all the time i ran yesterday.

  • Thanks 1

Share this post


Link to post
Share on other sites
Posted (edited)
16 hours ago, bocianu said:

just to change a subject... how's your investigation going foft?

is there any chance to revive sio interrupts? 

pleaaaase 🙏

Fixed🥳! I'll do you a private build later to try, which board do you have?

 

The problem:

i) I was using bit 0 of the control register for the edge, instead of bit 1 (typo 🙃).

ii) When in 'output mode' I was disabling irqa1 as well as irqa2.🥴

 

Lots of emoji's because my son is here and he likes them!

Edited by foft
  • Like 7
  • Thanks 2
  • Haha 2

Share this post


Link to post
Share on other sites

I do have purple one (mini) with smaller fpga. Thanks foft, you are awesome ;)

Share this post


Link to post
Share on other sites
Posted (edited)

After first tests PIA interrupt fix seems to work... partially.

By defaut #FujiNet sets low level on PROCESS pin for 50us.

50us looks enough for real hardware and interrupt gets triggered, but on Eclaire it's not detected.

After extending pulse witdh to 150us it also started to work on EclaireXL.

 

I don't know if it's possible to fix this issue on the Eclairs side, but I would expect it to behave like a real hardware ;)

Edited by bocianu

Share this post


Link to post
Share on other sites

Well it’s an edge detector, which takes 17ns:) Are you sure the level is really

changing properly?

Share this post


Link to post
Share on other sites
10 minutes ago, foft said:

Well it’s an edge detector, which takes 17ns:) Are you sure the level is really

changing properly?

It's been working for weeks or longer on several other Ataris.  It wouldn't be a big problem to change it on the FujiNet side, but it's strange that the Eclaire isn't behaving the same as original 8-bits...

 

Share this post


Link to post
Share on other sites

I checked the HDL again and see there is a missing synchroniser. Since it’s an async signal coming into clocked logic. Let me

add that.

Share this post


Link to post
Share on other sites

Anyway my question stands, can you show me the pulse on a scope trace please?

Share this post


Link to post
Share on other sites

I uploaded a version with synchronisers on the inputs.

 

I wondered another thing, could it be that the interrupt is flagged earlier than before then cleared with a read?

Share this post


Link to post
Share on other sites

Version with synchronisers needs wider pulse than previous one.

It started working at 200us pulse width. 

  fnSystem.digital_write(PIN_PROC, DIGI_LOW);
  fnSystem.delay_microseconds(200);
  fnSystem.digital_write(PIN_PROC, DIGI_HIGH);

Unfortunately I'm unable to show you the pulse on a scope trace.

Share this post


Link to post
Share on other sites
Posted (edited)

Ok, I need to experiment with known pulses.
 

The synchroniser just adds a 2 latch delay @ 56MHz to prevent meta stability. So a 34ns delay. Odd that’d increase the time required by 50us.

Edited by foft

Share this post


Link to post
Share on other sites
7 minutes ago, foft said:

Ok, I need to experiment with known pulses.
 

The synchroniser just adds a 2 latch delay @ 56MHz to prevent meta stability. So a 34ns delay. Odd that’d increase the time required by 50us.

This 200us time is only rough estimate. I was using 50us step to test it, because after each change I need to recompile firmware, upload it and retest. If you need more precise treshold, I can do some tests with more precise times.

 

 

Share this post


Link to post
Share on other sites
5 hours ago, jamm said:

It's been working for weeks or longer on several other Ataris.  It wouldn't be a big problem to change it on the FujiNet side, but it's strange that the Eclaire isn't behaving the same as original 8-bits...

 

in practice we try to never change what works on real hardware to fix things for emulations/simulations of any kind. It completely defeats the purpose of each of the different exercises... we want the original to operate as quickly and as accurately as possible, all others need to follow suit.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...