To infinity and beyond... (new hardware)

[reifsnyderb]

2 hours ago, Spaced Cowboy said:

That's *really* useful - thanks a bunch

 

Any time.   🙂

 

I've noticed one problem with the document thus far.  It is written as though the operating system enables or disables the floating point ROM at D800.  Only the parallel port device can disable the floating point ROM via the Math Pack Disable pin.  I am going to incorporate the document within my document and include notes as to clarify parts of the text I have some knowledge of.

[+Spaced Cowboy]

So I'm away at a conference this week, a rare event for me, but it means I actually have a fair amount of free time in the evening that's not taken up with household chores and kids bedtime rituals ... I made sure I had the PCB software installed on the MacBook, and have managed to get the design routed. The Design Rule Check is giving me 0 errors, so now it's ready for a first-pass through, manually checking all the connections (doing things like checking there's a connection to the +3v3 plane, rather than a bunch of +3v3 islands which aren't connected together. I never quite trust the DRC for that sort of thing :)

 

This is the dev-board, and it's got a whole bunch of pins and things on it that will be useful for debugging - I don't expect the final result to be quite so busy. Something of an oversight but the board is currently 101x106mm, and I was trying to keep it within the 10cm² area that gets you "cheap" manufacturing. When I remove some of the pins for a final run, there'll be sufficient space to recover that, though.

 

Anyway board-porn enclosed. Enjoy

 

FYI Back-panel Left->Right is 

• Ethernet
• RP2040 (board controller micro) enter-DFU-mode button
• USB connector
• BL702 (JTAG interface to the FPGA) flash-new-firmware button
• Stereo audio in
• HDMI out
• Power in (not sure if the 8-bit will have sufficient power available, so the board can be externally powered)

The button on the left side is a reset button for the system-controller (the RP2040)

 

There's another 14 pins on the FPGA I'll probably bring out (because why not) and put on the RHS of the board. Maybe someday when chip-prices are no longer insane, a RPi-zeroW2 could be connected there... 

 

 

 

[reifsnyderb]

What FPGA are you using?

[+Spaced Cowboy]

It’s the Tang Primer 20K module from SiSpeed. I eventually went for the 20K (@$21) rather than the 9K (@$14) for a few reasons:

• The FPGA fabric is about 2x the speed on the 20K
• It also, as evidenced by the name, has ~2x the logic resources
• There’s a lot more io pins available on the SO-DIMM rather than the PDIP form-factor
• There’s access to the FPGA JTAG pins without having to fiddle with USB switches and temporarily switching the RP2040 into host mode. That was just .. bleergh.
• It comes with a 1 Gbit DDR3 already bound to the FPGA. I think this will be the largest memory expansion ever for the 8-bit Atari, providing 128MBytes of RAM
• They’re readily available on Aliexpress.
• The absolute price difference is fairly small

 

It’s the same basic design as before, just a different physical interface, and I don’t have to time-multiplex the address/data bus to the A8, which is nice.

[+Spaced Cowboy]

This is probably boring to those people not sitting in front of a computer and typing things into various forms on various screens to get the BOM together, but this has been my day, so y'all can suffer along with me 

 

The BOM is now more or less done - actually doing it raised a couple of red flags on a couple of parts I'd originally chosen and not paid attention to availability - there's one capacitor that AVNet have 200-odd of, and no-one else in the world does ... Not a problem to swap it out for something a little more available. Also LCSC are not on the automatic list of "go search for the best options for this BOM", so the initial price for an order of 5 boards was up in the $3000 range. The parts *were* available, but only in large quantity, so the application happily "ordered" me several thousand (twice!), when I needed 10.

 

Anyway, for a small-quantity (5) order, the components price comes to about $43, falling to about $30 for a larger (100) order. That's without the FPGA/DDR SO-DIMM, so add another $21 onto either of those. Also without any power adaptor (although the board is designed to take anywhere from 6-12v, and most people have a wall-wart hanging around, even if the A8 can't actually power the thing itself).

 

Notable also is the lack of a case - at some stage I'll put together a 3D printed one. Not a priority right now...

 

There's also the cost of the PCB (about $4 for q100) and assembly (about $8 for q100). Altogether that should make the creation-cost to be about $70 for a largish order (Q100). It's a lot less economic at the Q5 scale, mind  

 

Talk of larger-scale orders is a bit premature, I need to know that this board works first, and there's going to be a lot of work to get the firmware / verilog done, but it ought to give a ballpark idea of where we'll be at, assuming it all goes well.

 

[+Spaced Cowboy]

Ugh, so I got to that point where I'm about to press the 'Make this!' button, and I'm going over the specs one last time, and then I noticed the top-layer of the PCB has to be 1oz or 2oz copper, it can't be 1/2oz like all the other layers.

 

Normally I wouldn't care at all about a trifling little detail like that, but on this board there's a bunch of impedance-managed traces, either because someone decided it was a good idea (yes, USB, I'm looking at you. 12MHz does not require managed impedance. It just doesn't) or because their data-rate is high (100MHz for ethernet) or very-high (750MHz to 10GHz for HDMI). The difference in copper thickness was sufficient to make my nicely-routed-and-length-matched differential pairs out of spec

 

So this morning/afternoon was spent redoing the DRC rules, the X-trace rules (traces that flow through other components like capacitors, so you can track the total end-to-end length), ripping up the above-mentioned length-and-impedance-matched traces, and redoing them, then running the DRC/fixing again until it came down to 0 errors. The HDMI differential traces are length-matched to within 0.1mm.

 

And *then* I could generate the Gerber/Placement/BOM files and send them off. So the below is now in the hands of the fabricators, I've asked them to go over it with a fine tooth comb because this is actually the first time I've used Altium to make a board.

 

The board hasn't changed massively since the last time, just some more labelling to help with "what does this pin do" without having to refer to the schematic, and I brought out the spare pins from the FPGA - the 3.3v ones anyway. There are 13 lines available, which is *just* enough if I were to ever want to interface a Raspberry PI over SMI - which gives a high-bandwidth, low-latency interface to the PI's memory using DMA and FIFO buffers on the Pi side to counter the inherent problems of hard real-time access to a multitasking OS like Linux. SMI would require 8 bits for data, 2 bits for select ( used as read/write clocks), 2 bits for DMA request (one per dir), leaving one bit left for 'address' (which is really chip-select). That's 13, not a bad trade for a 50MB/sec peak bus  

 

[+mytek]

Wow that's next level engineering

 

I wouldn't even know where to begin with something like that, and way beyond my skill set for sure. Impedance matching via the PCB... Geeze definitely "to Infinity and Beyond"

 

Altium. Isn't that the big brother to Protel 99 SE? reason I ask is that I just started using that application for doing schematic capture for CPLD design using the ATMEL ATF1500A a 5V variant (still in current production, available from Mouser, Digi-Key, ect. and cheap). Since the Protel app is so old (nearly 2 decades) I found a free version on the web. And although I'm only using it to generate the CPLD JED from a schematic, it looks to be a very good PCB design application as well. I run it in VirtualBox using Win2K for best compatibility, and I gotta say even for the time this program came out, it's still impressive in this day and age. I think when it was originally released in the early 2000s it sold for $2K.

[+Spaced Cowboy]

To be fair, impedance matching sounds like it ought to be a lot more difficult than it really is - assuming you run the differential _P/_N traces on the top or bottom layer, all it comes down to is knowing the distance between the trace and its nearest (GND, +3v3, +5v) plane (which you get from your layer-stackup), and then you set the width of the trace to be X and the distance between the _P/_N traces as Y. That's it. There are online calculators to work out X and Y for this simplest case, and you just have to fiddle with the numbers a bit (there are many solutions to the equations, so you nudge one value and see what happens to the others) until you've got  trace/space settings that work for your board manufacturer capabilities (and budget!) 

 

If you want to run diff-pairs on inner layers, with 2 surrounding planes, it gets more complicated. It's dominated by the closest one (and treating it as if it were an outer layer is a fair approximation) but you need a real EM-field solver to do it properly, and those get expensive, fast. There's a built-in field solver in Altium, which was one of the things that made me think about it.

 

The annoying part is when you have to combine the impedance matching with length-matching - HDMI, for example has 4 sets of diff-pairs (3 data, 1 clock) which run at scarily fast bit-rates. Each of those trace-pairs has to be matched to within a tight tolerance, otherwise at high speeds bits from one 'clock' will be arriving at the destination at the same time as bits on another trace-pair from a previous 'clock'. Given that, you're wiggling the traces serpent-style to make one set of traces match the length of the others.

 

Now, do I think that we'll run into that on this board ? Not really. I'm looking at pixel/line doubling the XL output (to 640x480) just to get it fast enough to be in-spec for the lowest-possible HDMI signal frequency. We almost certainly won't be stretching the HDMI protocol with this setup [grin]. OTOH, the FPGA can potentially output 1080p (though not with audio mixed in, AFAICT), and I remember well that demo of the Acorn Archimedes where they were playing Zarch at the launch, and everyone was oooh-ing over the quality of the graphics, and then they shrank the window, and you could see it was playing 8 at a time... So I'd rather try and keep it in-spec, and see where that takes us eventually, compared to "well, it's good enough for what I want right now".

 

And again, I have to admit that the software helps a lot - instead of lots of trial and error, I set up rules that say

• This set of traces (that goes through capacitors and has resistors to 3v3 on its route from A to B) can be considered to be one 'X-trace' that I want to consider as one logical trace, call it X
• X has a sister-trace Y and together they form the differential-pair XY
• XY is in a group of traces {XY} that must all have *this* impedance profile (set up on the board-stackup editor) which defines the width of the tracks and the spacing between them
• {XY} must all be in the range L₁ to L₂ mm (and here, I just laid out the traces using simple point-to-point routing, took the longest one and said everything else has to match that)

Then there's an interactive tool that lets you define a rectangle within which the software will "wiggle" the traces, so by changing the bounds of the rectangle (and configuring things like miter, amplitude, step off to the side) you can relatively easily length-match these complex traces...

 

There are some other concerns - you shouldn't do what I've done here and use vias to go from layer to layer, but in my case these are the best pins to use (they're length-matched on the DIMM that the FPGA comes with) and I'm balancing the via-use with the other criterion of keeping the traces short. I've tried to mitigate that to the extent I can by making them all pretty similarly located. You also want to keep the diff-pair traces separated from other pairs of traces by more than the separation between the _P and _N, so there's that "blank" space between them. Again, I'm somewhat constrained by the layout choices of the DIMM itself, but I've done what I can.

 

So overall, it's not terribly hard to do this, it's just fiddly. With the bit-speed of HDMI (especially if it ever starts to get to higher resolution), the matching is important. It's less so for ethernet, and it's *cough* not very important for USB @ 12MHz...

 

 

Re: Altium...

 

It's a beast of an application - there's so much there that I feel I'm only scratching the surface. Certainly there's a lot of scope for me to grow into using it. Up until recently I was using Eagle, but Autodesk made it clear that they want to EOL Eagle, and move everyone to the cloud-based "3D-design package with an electronics module grafted on" that is 'Fusion 360'. It's also a subscription model, and while I don't really object to subscription models, I prefer to *buy* software. What I do object to is purchasing a 3-year subscription, then have Autodesk not release a single thing for 2 years. I think there's an implied obligation that if you take someone's money to rent out your software, then you'll continue to invest in that software over the time period. Autodesk disagree.

 

So I switched jobs, and got a signing bonus (which was nice). Part of that went to pay things like property tax, paying off the car etc. but some of it went to buying a permanent license for Altium. Altium is expensive but I figure I've been using Eagle for almost 20 years now. I can't see myself *not* wanting to do electronics as a hobby, so if you amortize the price over another decade or so, it's still in the ball-park of what I'd have been paying anyway with F360, and since I'd soured on Autodesk's shenanigans, I took the plunge. 

 

Altium is a lot more "grown up". Eagle was a bit more friendly in some respects, but Altium is a lot more capable. It's also designed for more procedural workflows than a single designer doing stuff at home - there's a lot of "commit this change, produce this change-request, merge the change-request into the board" kind of feel, rather than the "put down a component on the schematic, oh there it is waiting to be placed on the board" that Eagle was like.

 

OTOH, Altium gives you a whole bunch of things I probably don't even know about yet Amongst the things I have found, there's much nicer BOM management, an integrated field solver for those diff-pairs (which works better than the online calculators), and a nice 3D display... I've actually found this last useful for positioning things like switches/ports on the edge of the board. The 2D footprint doesn't always coincide with where the component edge is, it's more concerned with pads and locating the component that way. Using a STEP model from the manufacturer, you can see exactly where the power-jack body will be. I also managed to place a mounting-hole slap bang in the middle of one of the DIMM pads underneath the board, it got lost in the muddle of layers in 2D mode until I flipped it over and it was glaringly obvious.

 

 

Lest you think it's all sweetness and light though, I got an email back from the fabricators this morning, asking for Gerber files that actually include drill holes   And a board outline  I'm still learning here... They also sent me a request to "review" the BOM which normally means they can't source something, but I'll look at that later.

 

I think Protel was the original Altium and got rebranded! 

 

Enough, it's 9:00am, time to get to work

 

 

[+mytek]

Thanks for the thorough explanation. I think I learned a thing or two

[+Spaced Cowboy]

There's been some back-and-forth with the board hardware and the PCB-maker (this is the first one I've done in Altium and there were a few things I didn't get right the first time) but it's now in the hands of the PCB-makers, and if I'm lucky it'll be back around Thanksgiving. Hardware development is therefore on-hold for a while, as the board is fabricated.

 

In the meantime, I've been noodling around thinking about what it could do, and how that might be best exposed as features. I think one of the obvious benefits to using the board is the memory management. It seems to me that there's a couple of things that could really help out the 6502:

• A more-capable ALU. The Apple-II actually had a built-in virtual-machine that was 16-bit ("Sweet 16") to provide a general purpose way of using 16-bit arithmetic, and to reduce complexity when writing more involved code. I'm proposing to extend that extension, and introduce a simple 8,16 and 32 bit environment that's easily accessible via the 6502.

• There is a lot of memory on the FPGA board. More than any 6502 could realistically use. As a matter of course, I'm planning on having the memory in page-0 served by the DRAM on the board rather than from the internals of the machine.

 

Memory

 

BASIC takes over the top half of page-0. Getting rid of the need for BASIC (and providing an alternative) therefore gives a huge landscape of page-0 space for use and abuse and the fine-grained remapping abilities are what makes this whole idea really appealing. The proposal is (this is from the top of my RegisterFile.h header  )

 

/*****************************************************************************\
|* Registers
|* =========
|*
|* Registers on the 6502 are ... limited. The compiler therefore uses zero-page
|* space as storage for generic 32-bit (int,float), 16-bit (int) and 8-bit (int)
|* "registers", keeping track of what has been used where.
|*
|* The expansion board also allows the remapping of page-0 to increase the
|* number of registers available. Memory use is as follows:
|*
|*	 $1C,$1D  : 65536 sets of 8K banks to function RAM at $6000 .. $7FFF
|*	 $1E,$1F  : 65536 sets of 8K banks to data/fn RAM at $8000 .. $9FFF
|*	 $80	  : Page index for $C0..$CF  } compiler uses values here as
|*	 $81	  : Page index for $D0..$DF  } 8, 16, or 32-bit vars as
|*	 $82	  : Page index for $E0..$EF  } necessary
|*	 $83	  : Page index for $F0..$FF
|*	 $84	  : varargs count,
|*	 $85	  : varargs page index (vars start @0)
|*	 $86..$9F : global vars (not swapped, 26 bytes)
|*	 $A0..$AF : 16 bytes of function-return-and-args. Not swapped
|*     > $B0..$BF : 16 bytes of function scratch-space [indexed by $1C,$1D].
|*                               Not preserved over fn-calls
|*     > $C0..$FF : page-indexed variables [8,16,32-bit]
|*
|* >  means these variables are affected by the indices in zero-page
|*    ($80…$83 or $1C,D)
|*
\*****************************************************************************/

 

So let's go through this...

• The two pairs ($1C,$1D) and ($1E,$1F) allow remapping of the fixed address-ranges identified above, just by writing to these zero-page memory locations. Put $0000 into {$1C,$1D} and you have the "normal" memory there, put $0001 into the pair, and the memory at $6000..$7FFF is now the next bank up. Jumping ahead slightly, but it simultaneously remaps $B0..$BF as well, so each set of 8K "function space" can have 16 bytes of dedicated zero-page RAM associated with it. {$1E,$1F} does the same for the RAM at $8000..$9FFFF, and while this is "intended" to be for data (and note that screen-memory would fit here too) rather than functions, if you happen to have a function that's >8K, you could use both areas for functions.
• The next 4 bytes ($80..$83) each control 16 bytes in page-0. They allow remapping each section of 16 bytes to any of 256 possible locations - this gives you 4 x 16 x 256 bytes of zero-page RAM, or 16K. That's a lot of fast-access variables.
• There's a couple of dedicated bytes for varargs calls, which can supply up to 32 bytes of var-args to a function call. I think that's quite a lot, really, given that strings/arrays will be represented by pointers (2 bytes) rather than inline data.
• Then ($86..$9F) there's 26 bytes of un-swapped data, free for the compiler to associate as it sees fit. I'm thinking global variable stuff here - with a "usage" heuristic to determine which are the lucky dedicated variables to use. I'll do register-coloring to see if we can re-use any of them at different times (eg: loop vars) 
• Then($A0..$AF)  we have 16 bytes of function interchange memory. I think 16 bytes is pretty reasonable. The compiler ought to be able to know what the function signatures are, so it can pack in bytes, words, longs etc. efficiently. Anything that spills over can go on the stack, or maybe it's just a language limitation, and you ought to pass a pointer to a class instead. This memory will be used for passing return-values from a function back as well, and since I intend to allow multiple return values, the same rules apply to both in and out values.
• Then ($B0..$BF) there's the function scratch-space that's per-function
• Finally ($C0..$FF) you have the remappable memory for lots of zero-page variables.

 

The ALU

So that covers how page-0 could be used. The other thing I mentioned was a better ALU - a "Sweet32" if you will. The idea is to use a dedicated set (not quite sure if it'll be 2,3 or 4 yet) of bytes in page-0 to define an action for the FPGA to take on memory that is currently representing page-zero. That's very generic and sounds confusing, let me give an example.

• Let's say we use $86 as 'command', $87 as 'reg1', $88 as 'reg2'. This could be reduced by packing bits into values but conceptually it's easier to keep them separate
• The assembly looks like:

move.4 #$12345678 r8
move.4 #$87654321 r9
add.4 r8 r9

 

What that translates to is:

; move.4 #$12345678 r8
LDA #$78
STA $E0
LDA #$56
STA $E1
LDA #$34
STA $E2
LDA #$12
STA $E3

; move.4 #$87654321 r9
LDA #$21
STA $E4
LDA #$43
STA $E5
LDA #$65
STA $E6
LDA #$87
STA $E7

; add.4 r8 r9
LDA #8
STA $87
LDA #9 
STA $88
LDA #OP_ADD32
STA $86

The act of storing data into $86 (in this case) is what triggers the FPGA to update the 4 memory locations representing 'r9' that map to $E5..$E8. It does that really fast, which means the next thing the 6502 can do is read out the values of a full 32-bit addition... Same for mulu.4, muls.4, divu.4, divs.4 etc. etc.

 

Now you wouldn't use it for an 8-bit ADC and maybe not for a 16-bit ADC/SBC but a 16-bit multiply, bit-shift or divide might be valuable, so the suffices .2 and even .1 are available, as well as .4. Standard maths ops are intended to be available, and even floating-point variants. mulf.4 will do an IEEE 4-byte floating point multiplication, and ftoi/itof will be there for translation between things that 6502 can handle reasonably, and the floating point values it's not so good at.

 

So I started to put together a design for a language, trying to balance ease-of-implementation as well as power-of-expression. I'm planning to use structs (actually classes, but a class without methods is just a struct) - not sure yet whether the data for any class will be stored alongside the class code (in the 8K space) which would make instance-vars easier (but not as fast as zero-page) or whether they'll be deconstructed into "normal" variables and stored in the many many page-0 "registers" we have. Still noodling on that one...

 

I got far enough to start to want to see things working (I like steady, incremental, tangible results) so I paused the compiler code and started on an assembler a few days ago. There's still a long way to go to make it fully usable, but it can currently turn some output from the compiler that looks like:

 

and turn it into a binary blob of data ("/tmp/out.xex" by default) on my Mac:

 

 

.. and then if I use PCLINK on the emulator to turn /tmp into PCL1:, I can do:

 

 

So it can do "Hello World!" at least . The plan is to start with the simple 6502 stuff, and then add things in as I go. In order, the current plan-of-action is going to be:

• I need to incorporate '<' and '>' operators to get the low/high bytes of a 16-bit value. Given I'm providing for 32-bit stuff, I may have to come up with a 4-byte version. We'll see. For 'Hello World!' I had to hard-code the values into the LDA because I couldn't (yet) parse out the 'data' label address  
• Arbitrary include files. Useful for library code - I had to cut-and-paste the definitions into the above, and I'd like that to be an automatically-emitted .include directive
• Macros. Macros are pretty much the same as .include from my perspective - they both just replace the currently-parsed token with a bunch of other tokens. Macros add arguments, but that's no big deal.
• There's some places were expression-parsing isn't happening (the one I know of right now is within a .byte/.word declaration, so I have a raw $9B rather than a symbol (EOL) there for now.
• Peephole optimisations. There's only 3 real registers, so maintaining what the values are and whether the LDx is really necessary oughtn't be too hard - and even looking at a moving window and seeing if there's a more-efficient way to order the opcodes seems reasonable. If I move an 8-bit value to a 4-byte register, this could mean 6 instructions, not 8, which is a significant saving.
• And of course the whole 'sweet32' implementation and page-0 manipulation. That's the whole point, after all 

 

I've been on-and-off thinking of writing a modern language for the XL for, oh, the past decade or so. The thing is that I've always got as far as looking at what I'm proposing to do, comparing it to Action! or similar, and thinking: "is this *really* going to be better than that" with the answer "probably not". I think, with the above, it actually might be...

 

We haven't even started talking about how qualifying a function as "fast" would automatically run it (within it's 8K chunk) on the much faster 6502 on the FPGA, and how the main problems with speeding up the 6502 don't really affect this setup (it's totally dissociated, but can be memory-mapped in at will). That's the sort of enhancement to think about *after* what I have is up and running

 

 

 

[+Spaced Cowboy]

Gah. Boards came back today, and (all very keen) I plugged it into the back of the XE. Oh wait a minute, no I didn't, it didn't fit! 

 

The board-house have made the thickness almost 1.8mm on the board, and it will get past the cartridge/ECI slot (which I've now measured as 2.1mm) but won't go into the actual electrical connector inside. Here's two versions (the one on the right is much older and nowhere near as capable) 

 

But measuring that one on the right gives me 1.52mm for the thickness of the board:

 

whereas measuring the new board gives me 1.77mm (both of these measurements with me pushing hard against the dial to get the minimum values)

 

Apparently that 0.25 of a millimeter is sufficiently important to cause issues  Both of these boards are nominally 6-layer (I like ground and supply planes when using FPGAs), 1.6mm boards. Slightly under is fine. Over is ... not.

 

It's pretty hard to get edge-on, in focus pictures of the two boards next to each other (newest on the right) because they don't balance or anything. This is the best I can do, together with pixel-measurements of the heights once they were on the computer...

 

[sigh] That was a long wait for absolutely nothing useful  There's no way I'm going to try and force the board into the XE - I have enough "spare parts" motherboards as it is...

 

 

 

[ClausB]

[ClausB]

Sorry. Didn't mean to kick you when you're down. Bummer about the thickness. I came to my senses a few minutes too late to delete the post.

[+scorpio_ny]

Would it be worth it to make an intermediate pass through adapter board?

Sockets on one end that accommodate the thick board and the other side proper thickness to interface with the 130xe? That way you can at least test the new build.

[_The Doctor__]

that add on pass through board can make changes adverse to proper function

[+Spaced Cowboy]

1 hour ago, scorpio_ny said:

Would it be worth it to make an intermediate pass through adapter board?

Sockets on one end that accommodate the thick board and the other side proper thickness to interface with the 130xe? That way you can at least test the new build.

 

5 minutes ago, _The Doctor__ said:

that add on pass through board can make changes adverse to proper function

This is true, but it's at least on the really-slow bus (1.79 MHz) part of the board. I will probably end up trying some sort of adapter - though I've pinged the pcb house to get their take too. Hopefully they'll issue a refund...

 

I was sufficiently paranoid to include 2 different (isolated) power supplies so it could be powered from the XL/XE or externally - and that means I can plug it in and work with it, so all I'd need to do is put together a quick (2 layer ) board a 0.1" header for each pin and I could solder bare wires directly to the edge-connector pinouts on this board. Not a total loss. Fugly, but not a total loss. 

 

Speaking of the external PSU, it at least passes the "does it immediately release the magic smoke" test, which means I can start to link it up to the Mac and see if I can program the various parts... I've just got the compiler/assembler to the point where it's "compiled" (not yet tested) its very first complete program with function support ('call' in the assembly language) from high-level source to low-level 6502 code, so I'll run through some debugging on that first - if I'm going to jump from one part of the project to another, I'd like to leave the software-side in a known-good point, otherwise I'll lose the context information when I eventually go back to it.

 

[+Spaced Cowboy]

2 hours ago, ClausB said:

Sorry. Didn't mean to kick you when you're down. Bummer about the thickness. I came to my senses a few minutes too late to delete the post.

No worries - not your (or my) fault, stuff just happens sometimes