Denial

Frustratingly slow progress, just not had the time to spend on this project much.

The SD2IEC is now all assembled and tested. I've used the wrong footprint for the RTC so it's patched up. It also survived me soldering it in upside down
The next task is to solder the PLCC sockets, I'm not looking forward to these.

Rather a long interval since the last post. Christmas happened, followed by vacation. I've spent far too much time on the hot plate (which still isn't complete). However, progress has been made.
The SMD PLCC sockets were difficult to hand solder. I again got too much paste under one and had to remove it. The plan for the future is to get some stencils so an even layer can be applied.

More mistakes were made. I had wired the data lines of the CPLD incorrectly in the schematic. I've patched up this board and I'm still re-routing for the next iteration of the PCB. I also chose a flash chip that was pin-compatible but didn't use the AMD programming sequence.

Just the label for the case to be ordered, then the next (final?) prototype to assemble.

Well done, keep going!

Awesome work, srowe! Very exciting to see!

Progress update: I've now got the next iteration of the PCB (with fixes). I switched the fabricator, I've got gold fingers plus chamfered edge for very little extra.
I have experimented with using a stencil to apply solder paste for the SMD sockets. It took a little while to get the stencil aligned but the result looks perfect.

I've seen glitches with the original board, I'm not sure if that's an artifact of some of the patching etc or whether it's cross-talk because of the way I've routed tracks. I'll retest on this new board once it's complete.

srowe wrote: ↑Sun Apr 06, 2025 12:19 pm Progress update: I've now got the next iteration of the PCB (with fixes). I switched the fabricator, I've got gold fingers plus chamfered edge for very little extra.

I have experimented with using a stencil to apply solder paste for the SMD sockets. It took a little while to get the stencil aligned but the result looks perfect.

I've seen glitches with the original board, I'm not sure if that's an artifact of some of the patching etc or whether it's cross-talk because of the way I've routed tracks. I'll retest on this new board once it's complete.

Can't rush perfection; thanks for doing this, and for the update! -OGM

pixel wrote: ↑Thu Oct 03, 2024 7:06 am

srowe wrote: ↑Sat Sep 28, 2024 2:59 am Sure, what do you feel isn't covered well in the current User Guide?

I found the programming section hard to understand although it should be quite simple. But this one I couldn't take to the pub and be done with it before the second pint.

I've started writing a completely new document to explain the FE3 architecture. It's unfinished but hopefully it contains the sort of information you were looking for

https://eden.mose.org.uk/download/FE3%2 ... 0Guide.pdf

It's entirely derived from my study of the schematic and the firmware, and writing a quantity of code that behaves as I expect. I wasn't involved in the original design & implementation so I'd appreciate feedback from anyone that was.

Simon

srowe wrote: ↑Fri Apr 18, 2025 1:57 am [...]
I've started writing a completely new document to explain the FE3 architecture. It's unfinished but hopefully it contains the sort of information you were looking for

https://eden.mose.org.uk/download/FE3%2 ... 0Guide.pdf
[...]

I am looking at it right now, Simon. Thanks much! -OGM

I've started writing a completely new document to explain the FE3 architecture. It's unfinished but hopefully it contains the sort of information you were looking for

https://eden.mose.org.uk/download/FE3%2 ... 0Guide.pdf

It's entirely derived from my study of the schematic and the firmware, and writing a quantity of code that behaves as I expect. I wasn't involved in the original design & implementation so I'd appreciate feedback from anyone that was.

This is excellent! I too have been baffled concerning how the FE3 is programmed. I already am beginning to understand more of it from your draft document. Thank you for your work on this!

I've completed an initial version of the Programmers Guide and updated the PDF in the link above. I'd really appreciate any feedback on how to improve it or to correct any mistakes.

This is excellent! Just a read through has made things vastly more clear in my mind. Now I'm off to start playing with it...

Seems good to me, but I found the original documentation sufficient, so I might not be the best judge.
The PCB looks nice!

srowe wrote: ↑Sat Apr 26, 2025 8:11 am I've completed an initial version of the Programmers Guide and updated the PDF in the link above. I'd really appreciate any feedback on how to improve it or to correct any mistakes.

Hello! The Programmer's Guide is very useful. I had been looking at translations of German documentation about the Final Expansion and your document is much easier to read.

There is a problem with the documentation which is common to both the original German and your version, which has to do with how the implementation of the 3K RAM at $0400-$0FFF (RAM1 RAM2 RAM3) is described. Quoting from your document, page 8:

"The RAM1,2,3 area, when present, always maps to the first 3KB of Bank 0 of the RAM device. This means in some modes it is aliased with the first 3KB in BLK1."

The German documentation does say this too. When I tried checking this on my FE Alpha just now, I found that the 3K RAM at 1024-4095 ($0400-$0FFF) actually maps to 9216-12287 ($2400-$2FFF) in BLK1 of Bank 0, in other words it is at 1024-4095 within the 8K of memory. That 8K of memory will always map in to BLK1 8192-16383 ($2000-$3FFF) in the FE banking scheme, there is no way to map it in anywhere else.

It is not at the first 3K of Bank 0, rather it is 3K which starts 1K after the start of Bank 0, and continues until the end of the first 4K of Bank 0.

I hope this makes sense. I've tried explaining it a few different ways in this post. From a hardware point of view this is the easiest implementation of how to map RAM1 RAM2 RAM3 into the 512K memory device. It's a lot harder to make addresses 1024-4095 for the CPU map onto 0-3071 for the SRAM device, and I'm not surprised to see this wasn't in fact done.

Most of the operation modes of FE use either Bank 1 or Bank 2 for the main BLK1 BLK2 BLK3 BLK5 chunks of memory, I can't see any other use of Bank 0 other than for the 3K RAM at $0400-$0FFF (1024-4095).

Richard

rga24 wrote: ↑Sat May 03, 2025 9:17 am There is a problem with the documentation which is common to both the original German and your version, which has to do with how the implementation of the 3K RAM at $0400-$0FFF (RAM1 RAM2 RAM3) is described. Quoting from your document, page 8:

"The RAM1,2,3 area, when present, always maps to the first 3KB of Bank 0 of the RAM device. This means in some modes it is aliased with the first 3KB in BLK1."

The German documentation does say this too. When I tried checking this on my FE Alpha just now, I found that the 3K RAM at 1024-4095 ($0400-$0FFF) actually maps to 9216-12287 ($2400-$2FFF) in BLK1 of Bank 0, in other words it is at 1024-4095 within the 8K of memory. That 8K of memory will always map in to BLK1 8192-16383 ($2000-$3FFF) in the FE banking scheme, there is no way to map it in anywhere else.

It is not at the first 3K of Bank 0, rather it is 3K which starts 1K after the start of Bank 0, and continues until the end of the first 4K of Bank 0.

Thanks for this, I had meant to write some test code to verify this but forgot to do so. Looking at the code in VICE it looks to work exactly as you say, it's a simple calculation for the address and mapping it to $2400 onwards makes sense. I'll update this and release a new version over the weekend.

Simon