My VIA seems to not be working...

[DerTrueForce]

I have altered the PLD equations to remove the /IRQ logic, and to add the /RD and /WR signal. That works as it should, but something is still not right, as the VIA is still not producing results. I shall have to check my programming. Here's what I'm running:

Code: Select all

.ORG $8000   ; ROM starts at $8000
 LDA #$FF    A9 FF
 STA $6003   8D 03 60   ; set the VIA port A to all outputs
 STA $6009   8D 09 60   ; set all bits high
 NOP         EA
 JMP $8000   4C 00 80   ; loop

[GARTHWILSON]

Quote:

Code: Select all

 STA $6009   8D 09 60   ; set all bits high

$6009 is the timer 2 counter high byte. I think what you want is STA $6001. Making the names of the registers to be constants and then calling them by name (like STA VIA1PA, for VIA#1, port A) will eliminate most such errors. There should be very few numerals in your source code.

[DerTrueForce]

Oh. Thanks! I'd thought that there was some such mistake in my code. Trouble is, I still hand-assemble it.
It's probably a problem, but I'm looking for some sort of IDE. I don't much like working in multiple windows(especially on Windows, where I'm limited to one desktop). I'll probably have to get over it, or write my own(the former is much more likely).

Thinking of assemblers, are there any that run on the '02? I'm thinking of implementing one on Ittiara, once I get everything going(As well as VTL-02, a text editor, an SPI EEPROM loader, and a ROM monitor). I'm not too likely to use one verbatim, though, as I have a bit of an idea of what I want already, so I may simply end up writing my own.

EDIT: I just tested it, and it was indeed me that was at fault.

[GARTHWILSON]

Here's the list of assembler links on my links page: http://wilsonminesco.com/links.html#assem (The second line links to a page with lots more links.) I just added this line a few days ago:

• SB-Assembler 3 (free) which now runs on Linux, MAC and Windows machines, and assembles for 6502, 65c02, and many other microprocessors and microcontrollers, announced Dec 7, 2016. There are also earlier versions available that run on DOS and Apple II and even Apple I.

Unless you're brand new to the instruction set, I think you're better off just using a good professional programmers' text editor like MultiEdit or UltraEdit, and a separate assembler. I don't use an IDE. An IDE and assembling on a 6502 machine are kind of at opposite extremes of the scale though. I use MultiEdit and C32 under DOS. There's no need for multiple windows when they load instantly anyway and MultiEdit goes back to the last set of files you had up with all the positions and blocks and other status just they way you left them. Actually, MultiEdit, even under DOS, does its own windowing, and I've had up to about 36 files open at once (most of them minimized but the rest layered and tiled and windowed in various ways). If I'm assembling on the '02, it's MultiEdit, and I "print" blocks of source code over the COM port to the workbench computer which takes the source code text and assembles, compiles, or interprets, as appropriate, on the fly, in the Forth system there. The editor never gets exited or suspended when I'm doing this.

[DerTrueForce]

For what I was going to implement on Ittiara, I have the idea that you'd enter the line, and it would assemble the code into memory when you hit enter on the line. And when you pointed it at an instruction, it would read it, and then disassemble that line, so that it can be read more easily.
I think the way you describe assembling on the '02 sounds really cool.

For an IDE, I was probably actually thinking of something like a text editor with an 'Assemble' button. I'll most likely do the bootstrap development in Pluma on Linux and Notepad++ on Windows, running the assembler on it with a script, and then writing it to the eeprom using the appropriate tool. A full-on IDE sounds like massive overkill to me. Although possibly quite nice for interactive debugging, if something like a Bus Bug was supported.

[BigDumbDinosaur]

DerTrueForce wrote:

For an IDE, I was probably actually thinking of something like a text editor with an 'Assemble' button. I'll most likely do the bootstrap development in Pluma on Linux and Notepad++ on Windows, running the assembler on it with a script, and then writing it to the eeprom using the appropriate tool. A full-on IDE sounds like massive overkill to me. Although possibly quite nice for interactive debugging, if something like a Bus Bug was supported.

You could also consider the Kowalski assembler/simulator, which is what I used for 65C816 development.

[barrym95838]

GARTHWILSON wrote:

...

• SB-Assembler 3 (free) which now runs on Linux, MAC and Windows machines, and assembles for 6502, 65c02, and many other microprocessors and microcontrollers, announced Dec 7, 2016. There are also earlier versions available that run on DOS and Apple II and even Apple I.

...

I'm still running version 2 inside a DOSBox, because I haven't taken the time to locate and install Python on my old Windoze Vista desktop. Maybe someday, but I don't think I'm going to hang on to this machine much longer anyway.

Mike B.

[DerTrueForce]

Trouble is, I'm after cross-platform tools if at all possible. Kowalski sounds useful, but it's Windows-only. I think I'll use the SB-assembler 3, as i actually already have it, as it turns out.

On a note more related to the original topic, the LCD display that I have isn't working. I've checked the datasheet(bad as it is), and it needs the R/W signal to be valid before the device is selected. I tried it with the pure-select, and also the gated select, and neither seemed to work. I might have borked up with the driver program, so I'll have to check that. There is also a possibility that it's cactus, as one of the glop-top ICs on the back got too hot to touch when I tried hand-driving it a while ago. In any case, I think that I really want to go to a graphical display if possible, so I may end up ditching the LCD anyway.

[GARTHWILSON]

If you haven't already, see the displays section of the 6502 primer, and the displays subheading of the circuits potpourri section of the 6502 primer, as well as the source code I have linked at both of these.

Note that the intelligent character LCD modules are not very fast; so if you put one directly on a 6502 bus, you're likely to go too fast for it. For this reason, ever since my first experience with them in the late 1980's with a 65c02 computer that ran at 170kHz most of the time to save battery power and kicked it up to 1MHz only when it had a string of floating-point calculations to do, I've always put the LCD on a VIA rather than directly on the bus. (This computer took about 2mA most of the time for everything, including the LCD.)

In most cases it's not really necessary to ever have the computer read the LCD, only write; so you can just tie the R/W\ line low, and just make sure you leave enough time between commands to make sure it has processed them.

The only graphics LCD I've used was interfaced by SPI, so that couldn't go on the bus anyway.

[DerTrueForce]

Looking at the datasheet, the minimum enable cycle time is 500 ns. This seems to imply that it can run at 2 MHz at most(less in practice). I did have the idea of winding up the clock speed later on, but if I sit the LCD on the bus, that'll put a hard limit of 2 MHz on the whole thing, unless I wait-state it, which I don't really want to do. I bought an Arduino Uno clone with it. I'll see about getting that to drive the LCD, and see if it's dry bread or not.

[GARTHWILSON]

Be sure to look at all the times. I grabbed a Hitachi data sheet that was near the front of a file here on this kind of LCDs, and for minimum enable time, it says 450ns, but cycle time is 1µs min. The R/W and RS have to be valid 140ns before enable goes true, and held 20ns after it goes false; so 450+140+20 is already 610ns, and that's before adding some delays for address decoding. Still, it needs time between enables, bringing the max to 1MHz if you time everything just right.

[DerTrueForce]

You are very correct.
The setup and hold times total to 110 ns. With the 500 ns min. enable pulse width, this reaches to 610 ns, plus 15 ns for the decode PLDs propagation delay equals 625 ns, for a maximum frequency of 1.6 MHz, according to my calculations. The LCD module is definitely not sitting on the bus.

Rats. Well, that's not the first ignorant mistake that I've made. I saw Ben Heck's 80's BASIC computer video on YouTube, and I thought I'd do something similar to what he did for the keyboard, and flash an XBox 360 chatpad. I didn't check the ebay page closely enough, and I ended up buying an unofficial one, which has no ISP header exposed. I tried writing a matrix-decoder Arduino program for it, and gave up when it became clear that it was going to be a disgusting mess. I've ordered an RC2014 serial keyboard, and I'll stick that on ACIA1, which was always going to be a KB anyway.

Thanks for pointing me in the right direction. You've saved me a headache down the road.

EDIT: I tried that Arduino program, and the LCD ain't workin'. All that's happening is that the data lines are set to $30, and the Enable line is being toggled, with 500 ms between each transition. Nothing is appearing on the LCD.

[GARTHWILSON]

Again, I think you'll find in the timing specs that there has to be some dead time between enables, in addition to the set-up and hold times, and that they limit the maximum speed to 1MHz and maybe less. The module needs time between bus transactions to process what you just gave it, before it's ready for another transaction.

[DerTrueForce]

I think I took that into account, but still, it won't run as fast as I want it to, and it also appears to be cactus(see my edit above).

[BigEd]

DerTrueForce wrote:

Trouble is, I'm after cross-platform tools if at all possible. Kowalski sounds useful, but it's Windows-only.

Just to note, Kowalski's IDE runs fine under WINE, which makes it cross-platform in practice. Both Linux and MacOS can run WINE (and DosBox too.)