Atari 800 XL Remake

[reifsnyderb]

2 minutes ago, ivop said:

The problems I'm describing are edge cases. 99% of the old-skool software will work just fine. The BCD thingy might influence BASIC floating-point timing loops, but not much else. Who uses BCD anyway? The shift/rotate ABS,x timing difference will be hit but rarely relevant. The R-M-W difference, well, I don't think you'll encounter the inc IRQEN trick before the year 2000, or maybe in a demo.

Well, you got me worried.  Making this board has been quite a challenge to say the least.  The latest problem was me finding out that Wincupl, the software used to program the CPLD's, wasn't creating the .JED file.  I was up to 4am working on this.  The solution may be to use a program called "Digital" by H. Neemann.  I had to redo the entire MMU code in basic logic circuits and hope to test it out tonight.

[ivop]

17 minutes ago, reifsnyderb said:

Well, you got me worried.  Making this board has been quite a challenge to say the least.

Sorry I got you worried That was not my intention. I totally overlooked that you didn't use Sally, even though I participated in this thread about the WaveBlaster overhang

 

Altirra does a good job emulating the 65C02, and indeed AtariSID stops working if you select that CPU. But most of the old software works just fine. As for inc IRQEN, I wouldn't be surprised if Project-M uses it, too. It uses timer interrupts instead of DLIs to toggle the GTIA mode on a per line basis.

 

Long story short, if you want 100% compatibility, you need Sally or a MOS 6502 with buffers to accommodate for the /HALT line.

[reifsnyderb]

2 minutes ago, ivop said:

Sorry I got you worried That was not my intention. I totally overlooked that you didn't use Sally, even though I participated in this thread about the WaveBlaster overhang

 

Altirra does a good job emulating the 65C02, and indeed AtariSID stops working if you select that CPU. But most of the old software works just fine. As for inc IRQEN, I wouldn't be surprised if Project-M uses it, too. It uses timer interrupts instead of DLIs to toggle the GTIA mode on a per line basis.

 

Long story short, if you want 100% compatibility, you need Sally or a MOS 6502 with buffers to accommodate for the /HALT line.

The Byte Attic circuit accommodates the /HALT line.  I never heard of Project-M and will look it up.  It sounds like, long term, a true SALLY replacement is needed.

Edited December 19, 2021 by reifsnyderb

[reifsnyderb]

Project-M  -->  Last update in 2018?     

 

[ivop]

8 minutes ago, reifsnyderb said:

Project-M  -->  Last update in 2018?    

Yes, that's the project I meant. Not sure if it uses this trick, but I'm sure there is other code that uses inc IRQEN. Perhaps @xxl can chip in?

 

As for a selectable CPU, I was thinking a 44p PLCC and a 40p DIP, but only one can be populated. You already have the /HALT circuitry for the W65C02, which is also needed for the MOS 6502b, and I don't think Sally would mind if you sort-of double that. So basically it's another socket that sits on the bus before the halt circuit? Just an idea. And it'll need more board space for sure, but perhaps not as much as you feared?

 

Edit: sort-of double that means you treat Sally like a regular NMOS 6502, ignore the halt line and implement that through a similar circuit the original 400/800 used.

Edited December 19, 2021 by ivop

[reifsnyderb]

3 minutes ago, ivop said:

Yes, that's the project I meant. Not sure if it uses this trick, but I'm sure there is other code that uses inc IRQEN. Perhaps @xxl can chip in?

 

As for a selectable CPU, I was thinking a 44p PLCC and a 40p DIP, but only one can be populated. You already have the /HALT circuitry for the W65C02, which is also needed for the MOS 6502b, and I don't think Sally would mind if you sort-of double that. So basically it's another socket that sits on the bus before the halt circuit? Just an idea. And it'll need more board space for sure, but perhaps not as much as you feared?

Well, the W65C02 and it's circuitry take up just slightly more space than 40 pin DIP.  So, it would basically double the space.

 

Though, this brings up an idea I had about making what amounts to something similar to an 800.  Basically, the main board would be a backplane with little to no extra circuitry (almost all connectors only) and everything would be add-on boards.  This could be put into an 800xl case.  So, the audio board would be an add-on, the video board would be an add-on.  Think like an early 8088...but Atari style.  The add-on boards could be either sockets or pin headers sticking out of the backplane.  So, if you wanted to use a SALLY, plug in a SALLY board.  A 6502 board could be plugged in or even a W65C02...depending upon which board you used.  It would be ultra modular and the main board wouldn't be much more than a huge bus. 

[_The Doctor__]

The 800 was designed for that purpose, right on down to the personality board... Icognito wouldn't have come about more than likely if it weren't in the 800 DNA nor the Bit3 or Franklin Card Video Card, not to mention memory upgrades, I/O cards et al.

Edited December 19, 2021 by _The Doctor__

[ivop]

19 minutes ago, reifsnyderb said:

Well, the W65C02 and it's circuitry take up just slightly more space than 40 pin DIP.  So, it would basically double the space.

 

Though, this brings up an idea I had about making what amounts to something similar to an 800.  Basically, the main board would be a backplane with little to no extra circuitry (almost all connectors only) and everything would be add-on boards.  This could be put into an 800xl case.  So, the audio board would be an add-on, the video board would be an add-on.  Think like an early 8088...but Atari style.  The add-on boards could be either sockets or pin headers sticking out of the backplane.  So, if you wanted to use a SALLY, plug in a SALLY board.  A 6502 board could be plugged in or even a W65C02...depending upon which board you used.  It would be ultra modular and the main board wouldn't be much more than a huge bus. 

This almost sounds like a miniature version of what I like to do with https://github.com/ivop/project-jenny

 

38 minutes ago, reifsnyderb said:

It sounds like, long term, a true SALLY replacement is needed.

I have been thinking about using the ARM processor used in the UNO Cart to implement a bus sniffing and driving 6502c implementation (cycle accurate). I acquired the dev-board, but beyond that I didn't do much more yet

Edited December 19, 2021 by ivop

[+mytek]

58 minutes ago, reifsnyderb said:

I never heard of Project-M and will look it up.

Not much to see other than a demo or two of moving around the maze (think 3D Wolfenstein). I believe development began in 2010, and there hasn't been much progress for several years now. Or at least that I'm aware of, maybe someone else knows better.

 

 

Project-M 2.0 (2010)(NRV)(-)(NTSC).xex Project-M 2.0 (2010)(NRV)(-)(NTSC)[a].xex Project-M 2.0 (2010)(NRV)(-)(PAL).xex Project-M 2.0 (2010)(NRV)(-)(PAL)[a].xex

[reifsnyderb]

1 hour ago, mytek said:

Not much to see other than a demo or two of moving around the maze (think 3D Wolfenstein). I believe development began in 2010, and there hasn't been much progress for several years now. Or at least that I'm aware of, maybe someone else knows better.

 

Project-M 2.0 (2010)(NRV)(-)(NTSC).xex 43.67 kB · 1 download Project-M 2.0 (2010)(NRV)(-)(NTSC)[a].xex 60.49 kB · 1 download Project-M 2.0 (2010)(NRV)(-)(PAL).xex 43.66 kB · 1 download Project-M 2.0 (2010)(NRV)(-)(PAL)[a].xex 60.46 kB · 1 download

It's amazing that much was done.  Very nice.  Too bad it wasn't finished.

[reifsnyderb]

Update:  

 

1.  Using Digital and re-creating the CPLD's in logic gates within the program worked.  Both CPLD's are programmed.

 

2.  The 600XLM refuses to boot.  The screen is garbled and shows intermittent changes.  Sometimes it's a white screen but more often than not it has some sort of flickering, blocky, pattern.  By testing the EMMU, I can show that the main memory is being accessed.  (i.e.  disabling the memory via the chip selects makes a huge change in that the screen turns almost all white with an ordered vertical band on it  ?   This also confirmed the EMMU CPLD is taking a program.)  So, I've got pins 14 and 15 disabled (via the EMMU CPLD) going to the memory so as to bring the main memory down to 16k and it does the same thing.  Pin connections have been verified with a meter.  Removing the BASIC ROM doesn't change anything.  The OS ROM came out of the dead 600XL and it's possible it's bad.  Without disassembling my 800XL I can't verify.  (I'd rather not do that as it works beautifully.)  I also discovered the 800's use 4k ROM chips so that's a no-go.  A burner should arrive tomorrow and EEPROM chips on Wednesday.  So I should be able to burn a new OS-ROM from a downloaded image and find out if this is the problem.  If it's not the ROM, it's either the memory or processor.  At one point, by pushing on the ROM it appeared text was displayed for an instant.  I am not sure as it was that quick.  Removing the ROM chip produces an off-white screen.  The video circuit was thoroughly checked with a meter and it seems ok as the sych is visible, voltages look correct, and line data section looks believable.   (lol)

 

3.  I think the MMU CPLD is correct as I used the info from a MMU file written by Bob Woolley and added the GTIA, POKEY, PIA, and J4CCTL based on the function of the 74LS138 connected to the 800XL MMU and verified everything with a memory map.  Digital allows for simulations and the simulation looks good.

 

4.  The other possibility is the CPU.  I suppose it's possible to run the CPU without ANTIC by holding the HALT line high.

[ivop]

23 minutes ago, reifsnyderb said:

4.  The other possibility is the CPU.  I suppose it's possible to run the CPU without ANTIC by holding the HALT line high.

I wouldn't recommend that. It's ANTIC that drives the HALT line, and halts the CPU. Not the other way around. Holding /HALT high will not tell ANTIC to not put its DMA address on the address bus.

 

Edited December 20, 2021 by ivop

[reifsnyderb]

4 minutes ago, ivop said:

I wouldn't recommend that. It's ANTIC that drives the HALT line, and halts the CPU. Not the other way around. Holding /HALT high will not tell ANTIC to not put its DMA address on the address bus.

 

I was thinking of pulling the ANTIC out of the socket and holding the HALT line high with a jumper.  

Edited December 20, 2021 by reifsnyderb

[reifsnyderb]

My reasoning is as follows:  HALT is active low.  So the CPU is "stopped" when HALT is low.  So, if ANTIC is popped out of it's socket and set on a table it won't be doing anything.  However, without ANTIC, the HALT line isn't controlled.  So, if I were to put a jumper in the socket to hold HALT high the CPU should determine it can run because ANTIC doesn't want the bus.  If the scope shows activity on the address and data lines, with only the CPU using them, it makes sense the CPU is probably ok.

[ivop]

I see. It wasn't clear to me that you wanted to pull the ANTIC out of its socket. Then indeed it's a good idea to pull /HALT high, instead of leaving it floating.

 

[reifsnyderb]

1 minute ago, ivop said:

I see. It wasn't clear to me that you wanted to pull the ANTIC out of its socket. Then indeed it's a good idea to pull /HALT high, instead of leaving it floating.

 

Yeah.  I re-read what I wrote and realized that it made sense to me only.   lol

[kenames99]

On 12/19/2021 at 11:14 AM, ivop said:

None of these will run on a 65C02: https://github.com/ivop/atarisid/tree/master/xex

 

The quote from Wikipedia explains it. NMOS inc instruction first writes the unmodified byte, and then writes the modified byte to addr. The CMOS version does not write the unmodified byte, but does a read instead, and then it writes the modified byte.

 

NMOS: two writes, one acks the IRQ, second enables it again

CMOS: one read, one write, no ack, reenable is useless, so it doesn't work

 

Edit: inc IRQEN is in this file (three times): https://github.com/ivop/atarisid/blob/master/irq.inc

hi ivop,

  the NMOS: line above explains that problem. thanks for clearing this up for me.

 

Ken

 

[+scorpio_ny]

Hi @reifsnyderb,

 

I was following this thread and concerning the the discussions about the sally CPU. I had done some reading and there is a project that may be of interest to you. Someone has emulated a 6502 using Teensy4.1 and a small board. It seems he was able to emulate the Commodore 64’s proprietary CPU and there was some discussion on trying to do the same for the Atari.  There is GitHub repository for the project. Here are some links:

 

MCL65+ 6502 Accelerator Board

GitHub link to project

Wordpress Blog link

 

He has posted some photos on his blog showing a Commodore 64 with his CPU replacement.

Since you are already discussing using Teensy 4.1, maybe this something you can incorporate? Hope this helps!

 

 

 

[reifsnyderb]

7 minutes ago, scorpio_ny said:

Hi @reifsnyderb,

 

I was following this thread and concerning the the discussions about the sally CPU. I had done some reading and there is a project that may be of interest to you. Someone has emulated a 6502 using Teensy4.1 and a small board. It seems he was able to emulate the Commodore 64’s proprietary CPU and there was some discussion on trying to do the same for the Atari.  There is GitHub repository for the project. Here are some links:

 

MCL65+ 6502 Accelerator Board

GitHub link to project

Wordpress Blog link

 

He has posted some photos on his blog showing a Commodore 64 with his CPU replacement.

Since you are already discussing using Teensy 4.1, maybe this something you can incorporate? Hope this helps!

 

 

 

I'll take a look.  Thanks!

 

[reifsnyderb]

Curiosity got the best of me and I took the 800XL apart.  

 

Both 600 XL ROM chips are good and run in the 800XL just fine.

 

The 65c02 was swapped the a new w65c02...same problem.

 

The memory chip was swapped with a new chip....same problem.

 

This leaves either some timing problem with the memory or the W65C02 halt circuitry.

 

If it's a memory timing problem, I might be able to fix it with the CPLD as the EMMU CPLD has both PHI0 and PHI2 signals....just in case.

 

If it turns out to be the W65C02 halt circuitry that circuitry is going in the garbage and I'll put a SALLY back on the board.   ?

 

Edited December 21, 2021 by reifsnyderb

[reifsnyderb]

I did a lot of reading about timing and no amount of EMMU changes made any difference.  I am now leaning towards the problem being related to some sort of memory corruption due to some problem with the CPU circuitry that handles the HALT operation.

 

I'll look at the board some more in the morning.

[reifsnyderb]

Here's my latest EMMU attempt. 

 

Banking1 is a jumper to configure the EMMU and is held high in this test.  (BA16-BA18 are set low)

BA14 through BA18 are the high address bits on the SRAM.  The idea is once this is working they can be used for banking.

 

I don't have other inputs in this attempt because they aren't critical to basic operation.

 

[_The Doctor__]

11 minutes ago, reifsnyderb said:

I did a lot of reading about timing and no amount of EMMU changes made any difference.  I am now leaning towards the problem being related to some sort of memory corruption due to some problem with the CPU circuitry that handles the HALT operation.

 

I'll look at the board some more in the morning.

do your mean MMU changes? You may need to alter both the MMU and EMMU

[+mytek]

You might want to double check your HALT circuit (or CPLD code if that's where it lives). Here's a working version based on the 65C02 CPU same as you are using, which uses discrete ICs that was developed by Guus Assmann.

 

 

And another one: Schematics W65C02S to Atari Sally Adapter 20 August 2020.pdf

 

Edited December 21, 2021 by mytek

[reifsnyderb]

8 hours ago, mytek said:

You might want to double check your HALT circuit (or CPLD code if that's where it lives). Here's a working version based on the 65C02 CPU same as you are using, which uses discrete ICs that was developed by Guus Assmann.

 

 

And another one: Schematics W65C02S to Atari Sally Adapter 20 August 2020.pdf

 

I used the schematic you have attached from August 2020 and just went over it completely again.  (This was the schematic I followed when I did the board.)  There are two differences between my implementation and the schematic.  

 

1.  The schematic shows pin 38 connected through the tranceiver (74hct245).  Pin 38 is grounded on the Atari so I skipped running pin 38 through the tranceiver to only ground it and just tied it to ground.  (Why would I run a ground line through a tranceiver when it's always ground anyhow??)

2.  I left the above tranceiver connection and the unused pin 11 tranceiver connection floating instead of grounding it.  While this should be fixed as it's bad practice, I don't see where it would have resulted in failure.

 

I don't see where either of these changes would be a problem.

 

I am now contemplating stripping all of the W6502 circuitry off the board and rigging it to a 65C02 SALLY just to see if this is the problem as I don't see any other reasons for this to fail.

 

Edited December 21, 2021 by reifsnyderb