Amstrad CPC Expansion Port Raiser with multiple edge connectors, any interest?

[LambdaMikel]

but my design based on a modern PIC mcu, would be  much easier and cheaper to make

yeah, there are many PIC and AVR-based designs for RS232 around. Most likely you will need a MAX232 driver/receiver though in addition, so it is not entirely trivial. 


https://www.allaboutcircuits.com/projects/how-to-use-max232-to-communicate-between-a-pic-and-a-pc/

[ikonsgr]

yeah, there are many PIC and AVR-based designs for RS232 around. Most likely you will need a MAX232 driver/receiver though in addition,

Max32 is needed when you want to convert signals from the "old school" RS232 +/-12volt signals to TTL signals. But since any serial interface available today (from usb to serial cables, bluetooth modules up to wifi esp8266 which is in fact 3.3volt but using a cheap coneveter you can feed it with 5volt signals) are using only TTL, i don't think this is neccessary any more.
And since i had i bit of experience with PICs,i end up using a small but rather powerful 8bit 16F1579@32Mhz, equipped with hardware serial interface (and that's why i manage speeds up to ~500kbit and maybe even more). Apart from it, i only used an extra 4002 logic gate chip (Dual Quad input NOR gate) to combine the required signals from amstrad (A5, A10, M1, and IORQ) , in order to issue a pause command to amstrad instantly, when an input or output command to the interface is given.

so it is not entirely trivial. 

Tell me about it...achieving the correct timing for turning PIC's data port (which is directly connected to amstrad's data bus) to output (in order for Z80 to read correctly the byte),and then to input (in order to detach pic's dataport from cpc's data bas and not intereffere other tasks ,READY signal pauses Z80, but all other systems inside cpc, are alive and working constantly.... :-) ), was a really HELL of job!  It took a lot of impovise (in software and hardware) to finally get this right...

[LambdaMikel]

Max32 is needed when you want to convert signals from the "old school" RS232 +/-12volt signals to TTL signals. But since any serial interface available today (from usb to serial cables, bluetooth modules up to wifi esp8266 which is in fact 3.3volt but using a cheap coneveter you can feed it with 5volt signals) are using only TTL, i don't think this is neccessary any more.

Interesting. I am wondering if old school hardware would be the primary target for a RS232 though... but then, I can't really think of any old school hardware. Maybe a telephone modem or the like

Tell me about it...achieving the correct timing for turning PIC's data port (which is directly connected to amstrad's data bus) to output (in order for Z80 to read correctly the byte),and then to input (in order to detach pic's dataport from cpc's data bas and not intereffere other tasks ,READY signal pauses Z80, but all other systems inside cpc, are alive and working constantly.... :-) ), was a really HELL of job!  It took a lot of impovise (in software and hardware) to finally get this right...

Yes, I struggled with this using the ATmega at 16 Mhz as well (for LambdaSpeak), and only could get the interface right (timing wise) by adding a flip flop as input buffer and line output driver with output enable as output driver. Now I have a generic solution for this, however, that should also work for all kinds of hardware extensions (just a matter of reprogramming the ATmega).

Originally I thought this could be done by the ATmega left alone, even interrupts turned out to be way to slow to react to the Z80 signals.


Maybe the PIC is better in that regard?

[ikonsgr]

I had the same feeling for the PIC i use. I thought "32Mhz, what a hell, it could do things MUCH faster than the poor old Z80@4Mhz".
But, it turns out that "Granpa" Z80 was really  tough to beat... 
At some stage of development,i was so frustrated of not being able to sync everything right (even having a salae logic analyzer to help, something always seems to be missed out), that i also thought the only way to do it right, was using an extra octal 3state buffer chip (which is as big as the PIC itself), between cpc's 8bit data bus and pic's data port, and enable it by IORQ signal (so the buffer would "Automatically" make the correct "latch/unlatch" of pic's port to cpc's data port).
But then suddenly...an idea "hits me", and using a rudimentary "sample & hold" circuit (just a small diode and a capacitor) of the READY signal that feeded a pic's input pin (this signal issued from 40010 gate array, is acting like "central synchronizer" on amstrad), and then constantly "interrogate" this pin (by issuing"start/stop" signals to z80 every 0.25uS=1T@4Mhz, from pic's program ofcourse), i managed to "bit bang"  pic's port at exactly the correct time!   It's worth to mention that even a tiny delay (from proper timing) of just 0.25uS caused problems! Also, it's very important to disable any interrupt routines using in your MCU probgram while you are in the execution stage of "latch/unlatch" port to cpc's databus. At the begining i forgot to do that, and every time a byte received by the interrupt routine, when this critical stage was executed, everything was f@$%d up!
The thing is that in the end (i'm dealing with this project since last year's summer...), i managed to keep the circuit as it was, without adding extra chips which would add complexity and cost (pcb's footprint is only ~5X3cm, and this includes a pause switch and a reset button too!). And ofcourse getting the satisfaction of "doing it only with a PIC,bro"! 


btw,LambdaMikel, what is the instruction time of the atmega? PIC i use, needs 4cycles for all instructions, so @32Mhz you get an actual speed of 8Mips, or 8 instructions/uS. And usually the simpler thing to do ,like setting a pin to high/low, needs 2 instructions, so in practice, the fastest actual speed of doing things with a PIC@32Mhz is 0.25uS. And for the simplest while loop you will need 0.75uS.

[LambdaMikel]

At some stage of development,i was so frustrated of not being able to sync everything right (even having a salae logic analyzer to help, something always seems to be missed out), that i also thought the only way to do it right, was using an extra octal 3state buffer chip (which is as big as the PIC itself), between cpc's 8bit data bus and pic's data port, and enable it by IORQ signal (so the buffer would "Automatically" make the correct "latch/unlatch" of pic's port to cpc's data port).

That's what I did until I switched to the Xilinx CPLD that does both input and output buffering (and address decoding of course) of the ATmega / CPC databus, and reacts to the IOREQ and RD and WR etc. It is like a "mailbox" and allows me to work asynchronously with the ATmega from the CPC. Is the PIC also doing the address decoding?

But then suddenly...an idea "hits me", and using a rudimentary "sample & hold" circuit (just a small diode and a capacitor) of the READY signal that feeded a pic's input pin (this signal issued from 40010 gate array, is acting like "central synchronizer" on amstrad), and then constantly "interrogate" this pin (by issuing"start/stop" signals to z80 every 0.25uS=1T@4Mhz, from pic's program ofcourse)

So you are "throttling" the Z80 by pulling wait states? That works, but it would be better if this was not necessary   Have you checked how robust this is with different CPCs and cable lengths and other hardware extensions, specifically the 4 MB RAM expansions? 

i managed to "bit bang"  pic's port at exactly the correct time!   It's worth to mention that even a tiny delay (from proper timing) of just 0.25uS caused problems! Also, it's very important to disable any interrupt routines using in your MCU probgram while you are in the execution stage of "latch/unlatch" port to cpc's databus. At the begining i forgot to do that, and every time a byte received by the interrupt routine, when this critical stage was executed, everything was f@$%d up!

Right, pin change interrupts make your life / timing hard. Best way to sample with a slow (16, 20 MHz) MCU is reading from the GPIO in a tight loop, with all interrupts disabled.

The thing is that in the end (i'm dealing with this project from last year's summer...), i managed to keep the circuit as it was, without adding extra chips which would add complexity and cost (pcb's footprint is only ~5X3cm, and this includes a pause switch and a reset button too!). And ofcourse getting the satisfaction of "doing it only with a PIC,bro"! 

Good achievement, congrats! I am wondering how duke is doing this with the M4 etc. His MCU is probably so powerful that it is not an issue either. The problem simply goes away with more Mhz and MCU power of course.

Maybe I'll look into using the 32 MHz PIC for my next hardware project as well; an additional 12 MHz over the 20 MHz ATmega 644 that I am currently using can make a big difference I suppose.

btw,LambdaMikel, what is the instruction time of the atmega? PIC i use, needs 4cycles for all instructions, so @32Mhz you get an actual speed of 8Mips, or 8 instructions/uS. And usually the simpler thing to do ,like setting a pin to high/low, needs 2 instructions, so in practice, the fastest actual speed of doing things with a PIC@32Mhz is 0.25uS. And for the simplest while loop you will need 0.75uS. Also, using interrupt routines issue a BIG penalty at actual speed, as the hole status of mcu must be saved to ram, then execute interrupt code, and then reload everything from ram, to start from where it's left, with pic this takes dozens of instructions, often more time than the execution of the interrupt itself!

AFAIK, ATmega / AVR is RISC and each OP requires 1 cycle only.

[LambdaMikel]

@Duke  , can you educate and enlighten us how you are dealing with that problem (see discussion?) M4 board has only one chip as well 


<-- getting popcorn now to learn from the master himself 

[ikonsgr]

That's what I did until I switched to the Xilinx CPLD that does both input and output buffering (and address decoding of course) of the ATmega / CPC databus, and reacts to the IOREQ and RD and WR etc. It is like a "mailbox" and allows me to work asynchronously with the ATmega from the CPC. Is the PIC also doing the address decoding?

The address decoding at my situation, involves only 2 address bits, and 2 cpu signals, so the "decoding" (=when amstrad cpc must pause and pic must be enabled)  is  done by a small and simple 4002 logic gate chip.I tried to do that using pic at first, but even this simple decoding couldn't be done fast enough. ...Propagating 10's, 100's or 1000's of signals simultaneously in blazing fast speeds, is the only thing that PIC CANT do well. In fact i think that, no MCU can do such things. If they could, then PAL's, CLPD's, FPGA's would be useless .
Btw, i heard (never involved with such things myself) that programming these logic gate array "monsters" ,like CLPD's and FPGA's, is very difficult and tedious task, the tools to do it are very complex and hard to use, is this true?

So you are "throttling" the Z80 by pulling wait states? That works, but it would be better if this was not necessary   Have you checked how robust this is with different CPCs and cable lengths and other hardware extensions, specifically the 4 MB RAM expansions? 

Well, not exactly. What i actually do, is to activate the "READY" signal which "tells" the cpu that it can't access  address bus and data bus (this of course, cause any program execution to halt,practically pausing amstrad). Anyway,i doubt this can do any harm as (and you might already know that) this is what gate array 40010 does ALL the time! It constantly issues a pulse every 1uSecond, at Z80's "READY" input , and only then, Z80 is allowed to access addr&data buses . Signal analysis also revealed that pulse width is 0.25uS (25% duty cycle), so in reality 75% of the time Z80 is... waiting   (fortunately most of Z80 commands need 4cycles to execute, so in practice this doesn't have any impact in performance as addr&data access is usually needed to accessed every 1us anyway) . I have checked the circuit with 3 different amstrad cpc 6128, but unfortunately i don't have any  expansion boards to test it along with it. I suppose that you must have a lot of expansion boards for amstrad,so maybe i should send you a board for more thorough testing 

Good achievement, congrats! I am wondering how duke is doing this with the M4 etc. His MCU is probably so powerful that it is not an issue either. The problem simply goes away with more Mhz and MCU power of course.

As you said, Duke is using a 32bit RISC MONSTER MCU that runs ,if not mistaken, @160Mhz!! (btw, the only person that might know the "inner workings" of an amstrad cpc better than Duke, might be... the one who designed Amstrad cpc... . The things he achieved with M4 board, and especially the writing of custom "amsdos" to enable "on the fly" loading of games directly from the net,is really unbelievable...just RESPECT! ). With that kind of power, timing issues are surely not a problem. I think i read in the thread of M4 board, where he explained some things, that he uses the same approach with my device, it sets ready signal so that amstrad will freeze, and then have all the time to do what it needs. Then probably unpause amstrad, but having so much power, synchronizing the "latch/unlatch" of cpc's data bus, would be much easier (and precise)  thing to do. 

[LambdaMikel]

Well, not exactly. What i actually do, is to activate the "READY" signal which "tells" the cpu that it can't access  address bus and data bus (this of course, cause any program execution to halt,practically pausing amstrad). Anyway,i doubt this can do any harm as (and you might already know that) this is what gate array 40010 does ALL the time!

Right, I am using this trick as well in one LambdaSpeak mode - of course, this gives you an arbitrary amount of time to process the IO request since you halt the CPC   This is also how you implement the Pause switch, right?

The only thing I think of maybe being critical is if the address decoding is not very selective (i.e., you decode a whole range), and then with a timing / hardware critical demo that controls the CRTC directly or the like the timing gets messed up if the expansion things it has to throw in a couple of wait states when it wasn't really addressed (I guess that could only happen for certain IO addresses being used by internal chips in the CPC, potentially). But I am not an expert in this either.

I suppose that you must have a lot of expansion boards for amstrad,so maybe i should send you a board for more thorough testing 

I'd be interested. I could connect my Tandy TRS 100 or TRS 80 Model 4 to the CPC over serial, with a terminal program or something like that for testing - to evaluate retro compatibility of RS232 

Do you have a CPC terminal program running / working with your card?

[LambdaMikel]

PS On a related note, are there any demos that crash when you hit the Pause button?

[ikonsgr]

Right, I am using this trick as well in one LambdaSpeak mode - of course, this gives you an arbitrary amount of time to process the IO request since you halt the CPC   This is also how you implement the Pause switch, right?

Yeap, just forcing READY signal to ground and everything stops!

The only thing I think of maybe being critical is if the address decoding is not very selective (i.e., you decode a whole range), and then with a timing / hardware critical demo that controls the CRTC directly or the like the timing gets messed up if the expansion things it has to throw in a couple of wait states when it wasn't really addressed (I guess that could only happen for certain IO addresses being used by internal chips in the CPC, potentially). But I am not an expert in this either.

The decoding ,only enables the pausing of amstrad and activating of the device, when input/output commands are given to specific ports, more precisely &FBD0-&FBDF (although i only use &FBD0 and &FBD1). I've loaded many games and demos with the device attached, and everything worked fine (just like nothing was connected :-) ).If you want take a look here . Also  the spanish guy who made the serial port based on the 16550 UART chip, can help you clear things out about "how and why" of the specific port used.

I'd be interested. I could connect my Tandy TRS 100 or TRS 80 Model 4 to the CPC over serial, with a terminal program or something like that for testing - to evaluate retro compatibility of RS232 
Do you have a CPC terminal program running / working with your card?

Yes,i have developed a small chat(e.g. terminal) program in locomotive basic (and also compiled it with turbo basic to have faster in response), which is tested with various terminal pc programs and seemed to work fine (i also test it with bluetooth module and my smartphone using a terminal program and chat seemed to  work fine too ), using serial cable, wireless bluetooth module and wifi esp8266 module (although the last one need some modifications in the basic program as it can't send receive bytes/chars directly, but through "encapsulation" with AT commands). You can also change serial port speed at any time by just issuing an "OUT &FBD1,x" command (where x is a speed code, 10,11,12.. up to 18, supporting speeds at 300,2400,9600,19200,38400,115200,230400,460800, i may add even more speeds as this can be done easily). I have also developed amstrad and pc programs for transferring files directly from cpc disk to pc and from pc to cpc disk. So the card will be ready to use for chat and file transfer, but since i'll give all the details about it , anyone could develop programs to use it!

[ikonsgr]

PS On a related note, are there any demos that crash when you hit the Pause button?

Not i'm aware of.

[pelrun]

even a tiny delay (from proper timing) of just 0.25uS caused problems

This is one place where the size of the numbers is misleading. 0.25uS seems tiny until you look at how long a 4MHz clock cycle is. That "tiny delay" is actually an entire clock cycle!

[Duke]

@Duke  , can you educate and enlighten us how you are dealing with that problem (see discussion?) M4 board has only one chip as well 

On the ARM cortex mcu's you can setup events on edge detection, similar to interrupts, except they have a lot less setup time.
So I setup edge detectors for RD & WR (earlier versions used ROMEN, IORQ, RD). Have a tight assembler loop with WFE (wait for event) and minimal gpio reading + logic to determine the operation.
Even with 168MHz timing is very strict.

For rom/ram emulation I cannot slow down the Z80 for proper operation, so that has to work realtime.

Simple example for address I/O decoding (this is could run fine on lesser ARM MCU as IORQ requests have lots of time to process):

Code Select Expand


mainloop:
        wfe
        ldrh        r2, [r0, #0x10]    @ GPIOB->IDR    (get IORQ,RD,WR)   
        ldrh        r3, [r0, #0xC10]    @ gpioE->IDR    (get a0-a15)   
        ands        r1, r2, #5        @ is it IORQ & WR                   
        beq        IORQ_WR                                           
        ands        r1, r2, #3        @ is it IORQ & RD       
        beq        IORQ_RD                                       
       
        @other code here if needed
       

....
        b        mainloop
IORQ_RD:
        cmp        r3, r8            @ is it port
        bne        mainloop   
....


For I/O operations like sdcard and wifi access, I use BUSREQ and BUSAK to halt the z80 execution when the final I/O kick is issued, in order not to maintain realtime rom board while the M4/ESP are doing longer operations. Another solution could have been to pull an I/O port to check if the operation was finished, but it would have had to run from RAM only.

When switching to cortex M7, I was still met with problems when wanting to do even tighter operations, the MCU while lots faster overall, its not any faster when doing simple test & branch instructions, so I took a complete new approuch.
I emulate every Z80 instruction in ARM assembly realtime, this way I can predict operations before they fully happen, so timing became much easier. This idea may work well for slower MCU's too.
So instead you have an edge trigger for M1 and decode instructions and their operations on the fly.

[ikonsgr]

For rom/ram emulation I cannot slow down the Z80 for proper operation, so that has to work realtime.

Well, that is definetely something you CANT do with a "humble" 8bit PIC@32Mhz i used... :-)

...Another solution could have been to pull an I/O port to check if the operation was finished, but it would have had to run from RAM only.

I believe this is what i did (sort of anyway), when amstrad needs to read the I/O port, without even using BUREQ and BUSAK. After initial pausing and execution of pic's code to issue the byte to the data bus, i unpause amstrad for just 1cycle=0.25us.During this time,a rudimentary "sample & hold" circuit of the ready signal (small diode+1nF capacitor), is pulled to some PIC's I/O port. After pausing amstrad again (using the very same ready signal), i check the level of the I/O pin, and if it's "high" means that Z80 has read the byte from data bus and so i can "unlatch" PIC's port from amstrad's data bus, by turning its direction from OUTPUT to INPUT. If I/O pin is low, then another "unpause/pause" loop is executed.

I emulate every Z80 instruction in ARM assembly realtime, this way I can predict operations before they fully happen, so timing became much easier. This idea may work well for slower MCU's too.

And this also something you CANT do with a "humble" 8bit PIC too....  


Btw, Duke, what's the cost of the ARM cortex MCU you are using? Did you program it directly with assembly? With such large and complex mcu,i suppose programming must be much more difficult than with an 8bit PIC i used..

[Duke]

And this also something you CANT do with a "humble" 8bit PIC too....  

Probably not, there's a bit messing about to get the flags right on the result of many instructions, this is where m7 executing two instructions in one cycle comes in handy - but lookups could be used instead to minimize that. I wouldn't try though

Btw, Duke, what's the cost of the ARM cortex MCU you are using? Did you program it directly with assembly? With such large and complex mcu,i suppose programming must be much more difficult than with an 8bit PIC i used..

It's cheap and yes all interface logic is in assembler, rest is in C (SD card, WiFi etc).
https://www.arrow.com/en/products/stm32f407vgt6/stmicroelectronics

Especially if you buy many.

M7 is not in good offers yet, when you need >=1MB flash + 512KB ram:
https://www.arrow.com/en/products/stm32f767vit6/stmicroelectronics



Also you can get the lesser cortex-m3 for around $2, I would prefer to use that over PIC/AVR

[ikonsgr]

Thanks for the info Duke!
Perhaps some day you should publish a study of "how to" you did the M4 board.
Especially the part of writing your own amsdos routines to replace disk access with direct sdcard card access, would be really interesting.
M4 will definetely fall into history as the board who brought Amstrad to the 21st century... 


Btw, for such a device,i would definetely choose another name than "M4", something more... "represantitave" of its abilities, like "SUPER BOARD, MAKE THE IMPOSSIBLE, POSSIBLE"...

[Duke]

Thanks for the info Duke!
Perhaps some day you should publish a study of "how to" you did the M4 board.
Especially the part of writing your own amsdos routines to replace disk access with direct sdcard card access, would be really interesting.

I made the source code for this available ages ago, here:
https://github.com/M4Duke/m4rom

There's not a lot to it.

M4 will definetely fall into history as the board who brought Amstrad to the 21st century... 


Btw, for such a device,i would definetely choose another name than "M4", something more... "represantitave" of its abilities, like "SUPER BOARD, MAKE THE IMPOSSIBLE, POSSIBLE"...

Thanks. Yeah I probably should have, too late - next generations have better names

[ikonsgr]

Just saw the M7 Galaxy board project of yours... It's like a borg invasion into amstrad cpc:


"WE ARE THE 'M' BOARDS, RESISTANCE IS FUTILE, PREPARE TO BE "CORTEX"-ASSIMILATED"....  

[Skunkfish]

Yeah I probably should have, too late - next generations have better names

M5? 
EDIT: Just saw the M7 / Galaxy board, I thought ikonsgr was joking!

[LambdaMikel]

Yes, the CPC is a really nice add on to the M4 

[LambdaMikel]

For the moment, i've tested it sucessfully with speeds up to ~0.5mbit (these speeds were "science fiction" back at the days of serial interface... ). I have also developed utilities for chat and file transfer  between amstrad and a PC. My intention is to make this a rather easy and cheap 'open source" project, where i will give everything for free (from board schematics and hex file for the PIC MCU, up to the utilities for pc and cpc), and, who knows, maybe in the future could establish a new "standard" for amstrad serial interface! Just imagine developing multiplayer LAN or even WAN games using it... 

I would have a first use-case: get one of these cheap 5 $ MP3 modules from Ebay with SPI / I2C / Serial Streaming support,
e.g. https://www.ebay.com/itm/SPI-Interface-VS1053-MP3-Module-Development-Board-On-Board-Recording-Function/321573958417?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649and use your fast serial interface -> SPI to stream MP3 audio to it. Voliá, 20 $ MP3 player for the CPC 

[ikonsgr]

Well,i don't know if CPC can "feed" fast enough this kind of board. Maybe if i sent you a board, you could try this and see if it works 
And i suppose that any board/device with serial I/O interface (and i think there are MANY of these nowadays, doing whatever you can think of...) can be hooked up to cpc serial interface! Then, it's only a matter of "managing" the data sent/received with a custom program, to make it work (which would be rether easy thing to do, using only a couple of inp() and out() commands, even from locomotive basic)! 

[LambdaMikel]

Well,i don't know if CPC can "feed" fast enough this kind of board. Maybe if i sent you a board, you could try this and see if it works 

Thanks for the offer, but I currently don't have enough time for this. I would buy one though when it is ready  Yes there is a lot or interesting serial hardware around. At some point I suggest somebody could make a plug in board for SPI / I2C / Serial / UART that would host all kinds of different click! boards from Mikroelektronika. And similar to your idea, one would only need to write "drivers" for the MCU to support a new Mikroelektronika click! board. But then, who needs all that stuff on the CPC... most people are fine with playing their games. CPC hardware development is *mostly* a hobby and occupation for the hardware designers themselves I believe.  Certainly one can't retire early from that. I think, with the exception of boards such as M4 and XMem and DDI3, if one can sell a dozen or so then this is already maxed out. But then, CPC hardware development is really mostly about the fun of "making" something IMHO. So I am largely doing this for myself, not for money or recognition or whatever other reason.

[TotO]

Right, and I am crazy enough to sell some of them assembled as "CPC community service" (no, can't retire early from this  )
https://www.sellmyretro.com/user/profile/cpcmichi/

I don't take care yesterday that was you that trying to sell those adapters so expensive... Why?
Can't you offer your time to the community like others doing dump, games and demo?

[LambdaMikel]

I don't take care yesterday that was you that trying to sell those adapters so expensive... Why?
Can't you offer your time to the community like others doing dump, games and demo?

Not sure I understand what you mean. For "community service", I have shared the Gerbers a long time ago such that people can build it themselves for  whatever price they can source the components for.  Same with the software.

https://github.com/lambdamikel/LambdaSpeak

I can't say / see that everybody offering hardware here has done that... 

You mean this one?

https://www.sellmyretro.com/offer/details/cpc-464-expansion-port-extender-32275

It is not expensive, if you consider that postage from the US is 14 $, and that's included in the price. So it is 20 $ only. The combined price for the 3 headers is 10 $ well. If you don't want it, assemble it yourself. Btw, the first batch I used OshPark PCBs which are much more expensive than Seeed studio.... 3 of these little board is 27 $ / 9 $ each. You are right, originally (last year or so) they sold for even more - but then, I found a better source for the angled IDC edge connectors, and I became better and faster at producing / soldering them, which took a while originally. And I guess other people might be better at sourcing components. Anyhow, I don't see I owe you an explanation for anything I am doing 

But in principle I also don't see anything wrong with getting reimbursed for the components and the time it takes to assemble them. Because these things also come with an opportunity cost. And yes, I try to "round up" to some extent to cover for additional material that I had to acquire, like soldering, test equipment, ... These costs go down the longer you are assembling and "producing" hardware I believe. If you don't like it or think it's too expensive, then don't buy and assembly it yourself from the shared Gerbers. As simple as that  AND not everybody buying / selling stuff on SellMyRetro or Ebay is from the CPC Community or giving stuff away for free either.

On a related note, I was wondering - where are the Gerbers and firmware files for XMem etc. btw such that people can build it themselves?  Are they shared somewhere?

But I was impressed that you can offer XMem etc. for such low / inexpensive price! I am not sure how you do this. You must have good component supplier. Maybe share some insights here how to produce hardware really inexpensive, that would be helpful.