Hello!
Long time member, but without writing anything.
Once upon a time (that's very long ago...) I had an AIM-65 as my first factory built computer. Now, growing old and tired of all the new ever changing crap I got an interest in retrocomputing.

I have start building a machine that is intended to, among others, run the slightly modified firmware from AIM- 65. This one is far from an electrical replica. I'm using the 65816 with RAM up to 512K and I/O at high addresses.

In addition to I/O changes, this arrangement makes some functions require modification. As the expected end of RAM never comes, it needs to be explicitly told a top address. That's easy where I have the source, but ran into problems when trying to start BASIC.

I'm not sure if it hangs in a never ending search for end of RAM, or f.ex. try to test keyboard directly or by an unfixed routine. Using my own software single step it get into some weird un-initialized memory fill. Billy Boy has outsmarted me on this... I have found some kind of source files, but they are cluttered with conditionals, making them unreadable.

As time passed my AIM got heavily modified, all software in RAM, and it worked. All ports at original locations. Everything worked perfectly. The answer now is not a hardware circuit to make a memory "hole". I want to fix the root cause in the firmware.

Now to my question: Can You please tell me something usefull about the BASIC initialization routines and/or "dirty" hardware access in that firmware? Pressing "5" just hangs before any output is given.

Thanks in advance for any help.


Edit: SOLVED!

As more I looked into the code, as more ridicolous it appeared. This can't be right, and it proved wrong!
The guy running this site http://retro.hansotten.nl/6502-sbc/aim- ... -software/ has made a mistake and swapped the rom images... The image he says is for c000 begins with two jumps, that makes sense. Prepared a new combined file, loaded and magic happened. BASIC started and runs perfectly...
Sorry for asking before thinking. I will of cource twy to write him a note about the error.

Welcome! Hans is a member here, but dropping him a note isn't a bad plan. Good to see you puzzled it out. An '816-based large-memory AIM-65-alike is a great project!

(I considered the AIM-65 as my first, but got a Compukit UK101 instead. Both single-board 6502 based machines, of course.)

I never owned an AIM-65 but we evaluated them as part of an industrial control lab at the uni where I was doing research stuff at. This was early-mid 80's. We had a big breadboard like thing and some pneumatic pistons, valves, etc. and the students would start by using pneumatic logic (who'd have though you could have an AND gate using pneumatics!) to make a simple sequencer, then progress on to TTL then an 8080 based SBC system.

I put together a simple system using the Aim 65 and it's BASIC to do the sequence - the bonus I gave them was that I could implement a time-out so that when a piston didn't reach the far-end it printed an error message up... That was hard to do using logic, easier, but still more code in 8080 but trivial in BASIC. Fun times!

I'd be interested in your AIM-65 look-a-like - please post photos

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Now I have posted a note on the Hans Otten site about the swapped ROM-files. Strange it has been in error for such a long time.

Here is a photo of the project. I think it's quite disappointing, still far from what the AIM was. It will never get a themal printer, but it will get the screen AIM never had. The unpopulated socket is meant for a 6345 CRTC and then there will be a few other sockets added for the rest of it. I like this solution better than a terminal over TTY.

The VIA has one of its ports connected to a 16F1459 that gives it keyboard input and file storage from my PC via USB. Linux of cource and the software in GCC. It's thought to work with the original casette commands, but instead save and read from a direcory on the PC. There are still a bit of work to do on that, but the winter is long...

The displays are HP matrix LED with integrated drivers, but no chargen. It uses the chartables intended for the printer and output through the VIA's shift register.

Almost all of this stuff was available at the time of the AIM, except that the logic was 74LS, not HC. The biggest difference is the RAM. Then I had two large cards with very expensive HM6116 chips to get just 60K (64 minus I/O space) of RAM. Now I have just one cheap chip that gives 512K.

Never say never.

Depends on how much you want it...

https://www.adafruit.com/product/597

Nice display!

Beauty is in the eye of the beholder - you made it and it's an AIM-65 like retro computer - nice!

My own project started off as something that might run Apple software, although it was no-where near Apple II like, but it mutated into something that would then run BBC Micro software - even though it was no-where like a BBC Micro!

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

_________________
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?

All solved now. The ROM files have names that identify the slot on the AIM 65 board, like xxxxZ23 to xxxZ26.
Added an image of the actual board layout also.

Now my machine have a working video display unit and I tried it together with the BASIC. There is a "reference card" telling about used zp addresses. The VDU needs three consecutive zp addresses so I tried a few outside of the indicated ranges, but they was very obviously used...

Do any of You know about any three consecutive zp addresses available when the AIM-BASIC is running?

No, but in the absence of proper documentation, then ...

How about writing a small BASIC program that copies ZP into an array using peek, then run something else in that same program - some simple maths, loops, gosub, then read and compare ZP with the saved array.

That's not 100% guaranteed to work (e.g. some edge case or lesser used function may not have been called - e.g rnd() and so on), but it might give you enough to get started ..

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Thanks! I'm becoming old that not thougt about this myself...

Did a simplified variation. Filled zp with a known value and then run BASIC. After that used AIM "M" function to view memory. Found that $e0 and a bit upwards was untouched and it apparently works.

When my assembler gets upgraded for the 816 there are better solutions available without the need for [zp] and [zp],y, that was easy to patch into the source as hex numbers. Just a long,x with 16-bit index will do the job much easier and more efficient.

When programming my computer I got some unexplained magical effects. Are there any known "special features" involved with the 65816 in emulation mode and the JSR (ABS,X) instruction? Most likely I have made an error, but I'm unable to find it...

JSR (ACTIONS,X)

seems to fail when the jump table and the routine resides in different pages. A routine in the same page works.

JSR LINK
- - - -
LINK JMP (ACTIONS,X)

seems to work just as expected.

That's very unexpected. We do expect wrapping within a bank, but we don't expect page boundaries to be important.
http://www.6502.org/tutorials/65c816opcodes.html#5.5

Thanks for answer.

As always, crap at the keyboard. An unrelated error caused just one byte in the jump table to be "bombed" and off we go into nowhere... I should know better after all those years than assuming software in RAM stays as it was loaded...

Sorry for taking up time with this.