74HC245 inputs are set some time before enable is asserted. Will check anyway. Regarding capacitive loading, wiring wise it should be about the same. Maybe the ROM and RAM address pins have different capacitance than those for data. As per the datasheet, for the RAM, those capacitances are 8 pF and 10 pF, so not very significant difference. ROM's pin capacitance is in that neighbourhood as well.

I'll try driving the data bus with a 74HC377 and see the result.

Sorry, I wasn't clear. With "ground springy thing" I'm referring to the scope probe accessory that lets you do away with the long ground lead. I used that where I could to better see the "real" signal, but it did not change traces much.

Juan

I drove address and data lines with my function generator, and data lines do show higher capacitance than address lines. But address lines are set up well before RAM is read or written. So I think this "bounces" are not much of an issue.

--------------------------

I finally found the problem with the random resetting. It only happened while typing, so it had to do something with the interrupts. I thought it was reading the return address wrongly and crashing, but its not the case.

Probing with the logic analyzer reveals that these Resets happen when interrupts hit just before the Instruction Register is loaded. My CPU handles IRQ by loading the IR with opcode $FB (I could also do it with $00, the BRK opcode, with a couple wiring changes and reloading the microcode, but it works as is...). The problem, and it is a design one and not a poor construction one, lies in that IRQ logic is asynchronous, so this timing issues do happen every once in a while. Synchronizing an internal signal to the rising edge of the clock (luckily I had a spare D flip flop that does just that) makes it behave properly every time. I've changed a couple wires and it now works flawlessly (or so I think). Same could easily be done with NMI, but it's currently disabled and I'm not planning on using it any time soon.
See the logic analyzer trace.

I've also removed the copper tape from the IDE cable. I don't think it did much.
Note that this has nothing to do with improper grounding and such. That is a separate issue.

So this means I can get on writing some code. I'll try to write a simple monitor and see if I can get some sort of BASIC going.
I'll update the schematics with all changes and publish them soon.
Juan

Glad to hear that you've identified one more of your sources of misbehavior in your processor implementation.

Asynchronous signals are the bane of reliable digital systems. I have for many years tolerated the additional latency that is incurred by using fully synchronous designs; especially for I/O, resets, and interrupts. The additional latency introduced by synchronization FFs can generally be accounted for, and the peace of mind is good for my health.

I don't mean to imply that I won't use the asynchronous resets of standard logic parts, or even those in programmable logic. Instead, I will drive those asynchronous resets / presets using a FF (or two) that synchronizes the signal to the appropriate system clock.

_________________
Michael A.

Definitely something to keep in mind for future projects. This is a learning exercise after all.

-------

So, in other news: Exams are over. [rant]We'll see if next year my university encourages teachers to actually do their job... [\rant]

That means more time to work on this. So far I've written basic screen routines: print a character (\n,\r,\b included), print a string (and a macro to print fixed strings, I'll try to include more macros in my code), clear screen and scroll. I've removed support for the character LCD. VGA is way more fun.

Regarding the PS/2 keyboard, in addition to regular ASCII characters and Shift, Return and Backspace, it now supports Caps Lock and Ctrl-C detection, which jumps to the monitor.

All of the above takes about 500 bytes for code and 1200 as character ROM and PS/2 scan codes to ASCII lookup table.

I've also just written a simple monitor that allows to Examine memory, Write to memory and Jump. It can be seen in use below. This takes and additional 500 bytes. I'm not very proud of my code, but it has been interesting to do binary to ASCII hex conversions and the like. It is attached below should anyone want to take a peek. Far from "production" quality and not optimized. I have a couple flow diagrams around. All will get published soon. I'm also working on tidying up the third revision of the Schematics.

Plans for the future:
-Implement the B flag so I can use BRK to get back to the monitor and what not.
-Write a mini-assembler, sort of like the Apple II. Writing machine code into memory is fun to an extent. I really want this to be able to work "stand alone".
-Get some sort of basic going. I have 14K of ROM left, but I would like to write some line drawing routines and such. After all my video card is graphics-only.
So anything under 10K or so should be fine. I really have no idea, and won't be doing much coding in BASIC. (I did some with the PICAXE micro-controllers some time ago, but don't remember much). Any recommendations? I still have to some research though.
-Write an UART in a CPLD, maybe based on Dieter's TTL UART.

Long road ahead...
Juan

I've implemented the b flag, now a BRK instruction gets you to back the monitor.
I also added a register that defines foreground and background colour for the screen. Not very useful, but fun.
The register that stores last keyboard code gets now cleared automatically after reading it, so I can easily check wether if the keyboard was the source of an interrupt.
----
I'm trying to get EhBASIC running. I'm not finding it particularly easy. I'm trying to see if I can assemble it in Kowalski's simulator, and then somehow link my assembled monitor and routines to that.

But for the life of me I cannot find a way to export assembled binaries from the simulator. It's hidden really well or I'm just plain blind. I couldn't find any documentation or user manual. Can someone point it out?
EDIT: Figured it out, its just File>Save Code. I thought that that was for the source code not the assembled version....

I also have some doubts regarding input and output routines, vectors and such, but I don't know if I should ask here or create another topic on the EhBASIC sub-forum.

I downloaded EhBASIC from here: http://retro.hansotten.nl/6502-sbc/lee- ... 502-basic/
Juan

great progress as always, honestly i envy your ability to be productive.
I try to finish one of my projects and then start watching Eureka again for the n-th time.

as for BASIC, you IO routines are technically be the same you use for your monitor.

though i'm not an expert with EhBASIC, i did get it working for my simulated system... i used WDCTools for it, but it was the 65C02 version of EhBASIC, i don't know if both versions work with the same assembler.

line 7723:


technically you should just replace the xxxx's with your routine addresses (if you know them) and it should work...

you can also place all your code at the end of the BASIC code or vise versa so you can assemble both and just use labels instead of trying to fiquire out absolute addresses manually.
that is how it worked for me atleast and i honestly cannot tell you what's up with the "V_INPT" and "V_OUTP" above it, they seem to be called multiple times but somehow it doesn't matter and it just uses the addresses from the PG2_TABS table...

EhBASIC is confusing, and i wish you luck

I'm trying to get as much done as possible while still on "University mode". Productivity then starts decreasing exponentially...

Here is some misc progress, I thought I separated things a bit:
Not much luck with EhBASIC, so I finished up the case to feel that I've got something done. I've made a board for all the external connectors, throwing in a DB9 in case I add a serial port later. This board also houses a 7805 voltage regulator that powers the whole thing. It was getting a bit hot, so I added a couple diodes on its input to drop the voltage from 9V comming from a wall-wart to about 7.5 V which is more manageable. The whole thing takes about 500 mA. It seems to be doing the business. Certainly better than wires hanging here and there.

I've also added a "dust cover" of sorts that flips open with a pair of hinges. See photos below:

So, regarding BASIC:

I've spent quite a lot of time reading EhBASIC's source and chasing things around. I just can't find the things I want... I like to comment my code delimiting the major parts, I can figure out the details if I need to. But I just find details and not the general flow of things on the BASIC source...

So here is what I've done so far:

On the BASIC source I've changed the following line:



And assembled it on the Kowalski simulator.

I wrote a couple routines to match what the mim_mon.asm example does. (Or I think it does). I only "initialized" INPUT and OUTPUT vectors, as I'm not doing anything with LOAD, SAVE or interrupts just yet.



basicStart is called by the monitor with the 'B' command.

I moved the monitor and I/O code to $F000, reduced the zero page use to a minimum, so the monitor only uses $e2 to $ee, which are said to be unused in the BASIC source, and moved the monitor's input buffer to the top of RAM, out of the BASIC area (That is $6F00...$6FFFF).

I also modified the monitor so upon a BRK it shows the program counter and registers, and also has ability to continue after the BRK, to aid in debugging. At this rate, my monitor is going to be pretty powerful by the time I get BASIC is running...

So, after joining basic and my monitor on the EEPROM programmer software, and programming the ROM, here is what happens:

I do get the Memory size ? prompt. Writing a number sometimes results in it giving a sensible output, others it gives random letters in place of the number of bytes free.

If I press CR, it goes on to detect how much memory is available. Sometimes it gives a number (not always the same one), others more random letters. (Which, in case it makes a difference, have bit 7 set).

Ignoring all this, if one types LIST or RUN, it responds with the usual "ready" as no program was entered.
Entering something like PRINT "HELLO" does in fact print HELLO, but actually trying to store a program in memory with line numbers does not. For example, after 10 PRINT "HELLO" and CR, it either executes a BRK and goes back to the monitor, or gets in an infinite loop. See "screenshots" attached.

I'm using the version of EhBASIC with the decimal mode patch, as my CPU does not have decimal mode.

So character input/output is working, but not much else. I don't really know what to to with this. One might suspect monitor and BASIC zero page overlapping or something, but I made sure I'm only using the bytes marked as unused on the source.

I read on this thread: viewtopic.php?f=5&t=5036 that $14 - $5A was allegedly free as well.

Any insight is certainly welcome.

Again, I'm not sure if I should post this here or create a separate thread on the EhBASIC sub-forum. I may try something like tiny Basic that I can perhaps understand more easily.
Juan

Everything is working fine now!

I tried Tiny BASIC from here https://github.com/jefftranter/6502/tre ... /tinybasic, and it was sometimes running fine, but then it would stop with an error. When listing the program, some characters had changed. So RAM was playing up again.
I just received 100 1n5817 Schottky diodes, so I added those to the address bus right on the RAM pins, where quite some overshoot and undershoot was observed. Now signals look cleaner and everything seems to work fine. I had the simple program shown below running under Tiny BASIC for about three hours without issue. (The four byte integer overflows, but everything works)

Now EhBASIC seems to work fine too. Now I have to learn a bit of BASIC to do something useful with it, and allow the keyboard subroutine to accept symbols like []{}+* and such, which is quite something. I also have to work on Ctrl+C, now it takes me back to the monitor, but it should go back to BASIC.

Juan

Well done! That's quite interesting - I don't think I've seen diodes used in that way.

Thanks! I hope it keeps working fine, because I don't really want to debug hardware and software at the same time...

------------------

I've written a couple of routines to draw lines between two points on the screen, based on the "Bresenham's line algorithm" https://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm
Wikipedia has a decent explanation and pseudo code for an implementation using only integer arithmetic. I've kind of translated that to assembly (not elegantly by any stretch). But it does work after a ton of debugging. Being able to add breakpoints and use my monitor to inspect registers has helped quite a bit. It does work now. Now I have to figure out how to call them with USR() in EhBASIC and such.

Juan

Glad you found an effective remedy. FWIW, it's possible to get diode arrays intended for clamping (see below). But the discrete diodes may be easier to retrofit into your project.

Similar devices include 74S1053 (which is 16-bit) and the 74ACT1071 and '1073 which are 10-bit and 16-bit clamp-diode arrays which also feature bus hold.

But.

You shouldn't be having this trouble in the first place. Why are the rise and fall times so much faster on your HC377's (which drive the problematic address bus) than on your HC245's? (Waveforms appear in this post.) Quite a few years ago I read an open letter to the industry which may have relevance. I doubt I could find it now, and I don't remember the author's name (might've been Dr Howard Johnson), but I do recall the issue.

The author complained that some chip manufacturers were migrating existing logic products to newer, smaller processes without notice. This may've been a money saver for the manufacturers, but the resulting increase in output rise and fall speeds was a clear threat to the functionality of their customers' designs. He explained the real and non-trivial risk that a circuit could already be successfully in production... then one day the boards rolling off the assembly line would start failing due to ringing and so forth. The author's goal was to raise awareness and to lobby manufacturers to stop "upgrading" their products without notice.

I don't know if there was much followup to this. But I suspect another solution for you, JuanGg, would have been to replace the HC377's you're using with HC377's from a different manufacturer.

-- Jeff

ps: nice work with the Bresenham!

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Good to know. Yes in this case discrete diodes were easier. Chips on the top, bodges on the bottom...
Hopefully my next project will span a single board, which means lesser problems in this respect.



I'll try to get hold off some chips from another manufacturer and try them out. The one's I'm using came from Digikey and read:

15CS1LK E4
SN74HC245N

95C1LLD E4
SN74HC377N

They are both TI parts.


Thank's! I wanted some line drawing routines in assembly as it takes an eternity to draw them from BASIC. (On what is effectively equivalent to a 6502 running at 500 KHz...)



Sounds interesting. I'm not really happy with my implementation so I may look for alternatives. (But one has to know when to stop...)
I've seen your demo on your 6502 primer (which I cannot thank you enough for). I've done a similar thing, generating random points in BASIC and calling the assembly routine to draw the lines. Nowhere near as fast as your demo. But it is fun.



Good reads. Something to keep in mind.

Juan

Some updates:

I've added a new heatsink for the voltage regulator as it was getting too hot. Now I can keep my finger on it for as long as I want, so it should be fine.
-----------------------
I've been working on the last card, the UART.
As I intended, I implemented it in a CPLD, an Altera Max II, which can be purchased soldered on a minimal development board quite cheaply, and its ideal for wire-wrapping. The downside is that it is 3.3V, so I had to use some level shifters. I had some of those bidirectional single MOSFET ones, so I used those. I added 74HC245 bus transceivers for good measure. I could have gotten away only using those on the data bus I suppose. I wired all address lines in case I want to experiment further.

I've been playing with Verilog (Learning the Art of Electronics has a brief intro to Verilog, I may later look at VDHL...) for a week, and I kind of know what does what, but a long way to go. Figured that getting an existing design up and running was enough of a challenge for a first project.

So the actual UART code I've gotten it from here: https//www.nandland.com/vhdl/modules/module-uart-serial-port-rs232.html.
I thought it would be more complex, but at the end of the day it's just a state machine.

I've written the address decoding side of things, some intermediate registers where data is stored before sending and after being received, flags and such. It can be configured by writing to a register to generate interrupts when a byte is received or when is ready to transmit again. I've used Dieter's TTL UART as a reference for this.
I had a couple problems with signals between two clock domains, phi2 and the CPLD's 50 MHz clock. Nothing a couple flip flops could't solve.

Baud rate is fixed to 1200, and I'm using the Data Terminal Ready (DTR) line to signal my laptop that the computer is ready for more data. This way I can just paste a BASIC program in PuTTY and it gets sent at the computer's pace. Seems to work fine.
Character drawing and scrolling for the graphics card can be disabled, and this speeds things up quite a bit.

I may write some routines for transferring data, but as of now, I can even use the monitor Write command to store bytes into memory directly.
-------------------------
I've written a simple program in BASIC that projects a 3d object made up of vertices and edges onto the screen. Line drawing is in assembly, but it's still pretty slow. When rotating a cube for example, by the time it draws it, one forgets where it was before. Still its fun.

I'm just rotating (https://en.wikipedia.org/wiki/Rotation_matrix) all the points and discarding the z coordinate.

I'll see if I can tidy things up and publish some code and schematics.
Juan