6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Mon Aug 19, 2024 11:39 pm

All times are UTC




Post new topic Reply to topic  [ 51 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: Mon May 29, 2017 7:11 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8497
Location: Southern California
Ok, take out the word "bus" in "bus contention." If the LCD is being interfaced through a VIA so it's not on the processor's own bus, you could have a situation where software is telling the LCD to output data to the VIA while the VIA is also trying to output data onto the same lines. Since it's going through the VIA, it will be staying that way a lot longer than just a half a phase-2 cycle. It will be there for at least a few cycles, possibly a lot longer than that. If the power supply isn't strong enough (evidenced by the dimming), the bypass cap.s get drained, and the voltage gets low enough that something doesn't work right. I don't know what the drive strength of the LCD is, but a W65C22S can do 50mA per pin when shorted.

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


Top
 Profile  
Reply with quote  
PostPosted: Mon May 29, 2017 7:29 pm 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
If you are using the primers scheme #1 then
+ (EP)ROM is from $8000..$FFFF and there is no contention possible.
+ RAM is from $0000..$3FFF and there is no contention possible.
IO-space ranges from $4000 up to $7FFF.
The IO devices are 'seperated' from each other by tying A13, A12, A11, ... and so on to their CS (active high) input. The active low /CS is tied to the coarse $4000..$7FFF selector signal.

Say you have a VIA-1 tied to A13 and a VIA-2 tied to A12. To access VIA-1 the address bus has to look like 011x.xxxx.xxxx.yyyy (x = 0 or 1 will work, y = tied to RS lines of VIA).
VIA-2 responses to 01x1.xxxx.xxxx.yyyy

As A13 is not checked by VIA-2 access to 0111.xxxx.xxxx.yyyy would select BOTH VIAs. Writing to $7xxy would push data into both VIAs - no technical but likely a logical problem. But reading would cause bus contention with more or less high current demands, likely to drop Vdd below RESET threshold.

So it is very important to use addresses with bit patterns that select only one device. In this case $600y for VIA-1, and $500y for VIA-2.

The 74HCT132 is OK.


Top
 Profile  
Reply with quote  
PostPosted: Mon May 29, 2017 8:02 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1945
Location: Sacramento, CA, USA
NickH93 wrote:
... Reading 4000, for example, the memory there just reads "40" from $4000 to $40FF, 41 at $41FF, and so on.

I'm not a hardware expert, but that sounds like a harmless floating data bus situation, where the third byte of the LDA abs instruction is persisting.

Mike B.


Top
 Profile  
Reply with quote  
PostPosted: Mon May 29, 2017 8:04 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3366
Location: Ontario, Canada
[I see Mike posted while I was typing this. Here's a more detailed explanation.]

NickH93 wrote:
Reading 4000, for example, the memory there just reads "40" from $4000 to $40FF, 41 at $41FF, and so on.

Hm, could be a serious problem here. This tells us no device at all is selected -- no memory, and no I/O. Is that what you planned? (I haven't been following this thread closely.)

The explanation for this behavior has to do with the 65xx's cycle-by-cycle bus operation. For example, LDA <absolute> takes four cycles -- three program fetches (possibly from EPROM) then the data fetch from the desired device; IOW we fetch the opcode, then the two operand bytes (ADL then ADH), then the actual data from the ADH:ADL address. If during the last cycle no device drives the bus then it can (due to its own capacitance) still have the value from the previous cycle -- ie, the 2nd operand byte, which is the ADH. That's why you invariably get "40" from $4000 to $40FF. You're getting the last operand byte -- ADH, the $40 -- not the data you expected.

LDA <indirect> will show the same behavior. The sequence of bus cycles differs; but, as with absolute mode, the next-to-last cycle fetches the ADH (from zero-page in this case). This can remain present if there's nothing to replace it during the final cycle.

HTH,
Jeff

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


Top
 Profile  
Reply with quote  
PostPosted: Fri Jun 02, 2017 1:34 pm 
Offline

Joined: Sun Apr 16, 2017 2:35 am
Posts: 34
So just a few updates. The keyboard interface broke (flimsy PS/2 socket), so I've since ported the monitor and basic to run off of my ACIA in the meantime (I have more sockets coming. I'm going to find a way to make it stronger). After finding out I had one with the TXE bug, I've got it displaying through a terminal. So now I have a full display. I've got different behaviors, but I wonder if this would help clear anything up. I've also went over all of my wiring and checked that it was okay for the whole board. I also changed the RAM chip, just to rule out bad RAM. I can read and write from this new RAM as well, just like before.

So, I see the memory count changing based on what I dictate for Ram_base and Ram_top. It seems to be counting the memory correctly.

Sometimes when I do a list command, it lists some random nonsense program even if I've typed nothing.

One time I typed in a program with lines 10 and 20. When I listed, it came out with the line numbers as like "10.xxxxxxxx" with, the x's being a bunch of random numbers. The program was then garbled after the line numbers too. This is weird, as with my old setup, it WAS listing programs correctly.

There are also some builds where everything gives me a syntax error.

Now though, when it crashes from doing a "PRINT A" command, it just freezes. It doesn't reset or anything. I've also confirmed my memory layout works in the Kowalski simulator

EDIT: Also, I forgot to mention. I noticed the mini_mon.asm for the simulator has a CLD command before running BASIC. I hadn't been putting one in for my board. Just resetting the stack. Would this cause issues?


Top
 Profile  
Reply with quote  
PostPosted: Fri Jun 02, 2017 8:22 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8323
Location: Midwestern USA
NickH93 wrote:
EDIT: Also, I forgot to mention. I noticed the mini_mon.asm for the simulator has a CLD command before running BASIC. I hadn't been putting one in for my board. Just resetting the stack. Would this cause issues?

Possibly. When in decimal mode the MPU has a markedly different behavior in processing the ADC and SBC instructions.

It's best not to make any assumptions about the MPU's state, including whether it is in binary or decimal mode. This is especially important with the NMOS parts, which do not initialize the D bit in the status register to any particular value following a reset or hardware interrupt. So what I would do would be:

Code:
;SIMPLE 6502/65C02 HARD RESET PREAMBLE
;
HRST     SEI                   ;disallow IRQs
         CLD                   ;ensure binary mode
         LDX #$FF              ;initialize...
         TXS                   ;MPU stack

   ...carry out other initialization steps as required...

         CLI                   ;allow IRQs...

   ...program continues...

Use the top-of-stack value required for your application.

The order in which this is carried out is important. The initial SEI is there to take care of the case where the HRST routine is called from software. A hard reset would automatically mask IRQs, but jumping to HRST would not without the SEI. Only after all initialization steps are carried out would you enable IRQs.

Unlike the NMOS parts, the 65C02 will clear decimal mode following any kind of interrupt, hard or soft (asserting reset is seen as a hard interrupt). Hence the CLD in the above would be redundant, but should be retained for the same reason that the SEI is present.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Fri Jun 02, 2017 8:37 pm 
Offline

Joined: Sat Dec 13, 2003 3:37 pm
Posts: 1004
You'd think if the Decimal flag was that important to the BASIC, they'd conspicuously clear it in the COLD START section.

(Not saying it's not important for it to be clear, just saying that BASIC should take responsibility for it's environmental requirements.)


Top
 Profile  
Reply with quote  
PostPosted: Sat Jun 03, 2017 2:56 am 
Offline

Joined: Fri Apr 15, 2016 1:03 am
Posts: 137
Quick check: what is A14 of the RAM connected to? Left floating would be bad.


Here is a sample memory test. It's currently packaged to run standalone, but you could integrate
it into your monitor. Fix the **FIXME** parts for your system.

Code:
; setup for ca65 from cc65.org
   .list on
   .listbytes unlimited
   .pc02   ;select CPU

   .org $10 ; direct page
MtStart: .res 2      ;test memory starting address
MtEndH:   .res 1      ;test memory ending address page
MtPass:   .res 1      ;pass #
MtPtr:   .res 2      ;current test memory address (lo byte is zero while running)
MtPat:   .res 1      ;expected byte value
MtDif:   .res 1      ;difference between expected & read byte value

   .org $ff00 ; ROM
Reset:   ldx #$ff
   txs

   lda #<$0020   ;Start=$0020
   ldy #>$0020
   ldx #>$4000   ;End=$4000
   ; call MTest (we'll just fall into it, since it's the only thing this sample does)


MTest: ;--- memory block test --------------------------------------------------------
   ; Doesn't use the 6502 stack (check "show we're still running") so we can check $0100..$01ff
   sta 0+MtStart      ; store parameters
   sty 1+MtStart
   stx MtEndH

   stz MtPass      ;for(MtPass=0; ;MtPass++)
@Pass:

   ; initialize test memory with pseudo-random sequence
   lda MtPass      ;  initialize LFSR
   ldy 0+MtStart      ;  for each page of test memory
   ldx 1+MtStart
@21:
   stz 0+MtPtr      ;    MtPtr=base of page
   stx 1+MtPtr
   eor 1+MtPtr      ;    shuffle LFSR on each memory test page
            ;    for each byte in page
@22:   lsr a         ;      cycle LFSR to gen next #
   bcc @23
   eor #$b8
@23:   sta (MtPtr),y      ;      store in test memory
   iny         ;      next byte in test memory page
   bne @22
   inx         ;    next test memory page
   cpx MtEndH
   bne @21

   ; verify test memory with pseudo-random sequence
   lda MtPass      ;  initialize LFSR
   ldy 0+MtStart      ;  for each page of test memory
   ldx 1+MtStart
@41:
   stz 0+MtPtr      ;    MtPtr=base of page
   stx 1+MtPtr
   eor 1+MtPtr      ;    shuffle LFSR on each memory test page
@42:            ;    for each byte in page
   lsr a         ;      cycle LFSR to gen next #
   bcc @43
   eor #$b8
@43:   sta MtPat      ;      save #
   eor (MtPtr),y      ;      compare with test memory
   bne @Err
   lda MtPat
   iny         ;      next byte in test memory page
   bne @42
   inx         ;    next test memory page
   cpx MtEndH
   bne @41

   ;show we're still running
   lda MtPass      ;  make up a char from MtPass
   and #$3f
   ora #$40
   .byte $02,$fd      ;  **FIXME** write a char to the console

   inc MtPass      ;  next MtPass
   bra @Pass


@Err:   ;verify found an error - save detail
   sty 0+MtPtr      ;MtPtr is the failing test memory address
   sta MtDif      ;MtDif is the difference between computed & read test memory byte
            ;MtPat is the computed value
   lda #'E'
   .byte $02,$fd      ;**FIXME** write a char to the console
   bra *         ;get stuck (maybe go back to monitor instead)



   .org $fffa ; 6502 vectors
   .word Reset   ;NMI
   .word Reset   ;reset
   .word Reset   ;IRQ & BRK



On EhBasic 2.22:
It does reinitialize the 6502 stack pointer the way it likes.
I don't see it clearing the D flag - oops, better clear it before entering EhBasic.

At http://forum.6502.org/viewtopic.php?f=5&t=4564 there is more discussion
also https://github.com/Klaus2m5/6502_EhBASIC_V2.22/blob/master/bugsnquirks.txt


Top
 Profile  
Reply with quote  
PostPosted: Sat Jun 03, 2017 3:26 am 
Offline

Joined: Sun Apr 16, 2017 2:35 am
Posts: 34
Thanks a million everyone for the help. I'm out all weekend so I can't try these fixes atm, but that linked forum thread duplicates my issues with my same kind of setup. So I'm going to try the fixes in the other post, see if they work.

I'll also implement this Mem test and clear decimal before starting.


Top
 Profile  
Reply with quote  
PostPosted: Sat Jun 03, 2017 7:04 am 
Offline

Joined: Sat Jul 28, 2012 11:41 am
Posts: 442
Location: Wiesbaden, Germany
whartung wrote:
You'd think if the Decimal flag was that important to the BASIC, they'd conspicuously clear it in the COLD START section.

(Not saying it's not important for it to be clear, just saying that BASIC should take responsibility for it's environmental requirements.)

It is cleared in the reset vector of min_mon.asm which is the environmental wrapper for EHBasic.
Code:
; reset vector points here

RES_vec
   CLD            ; clear decimal mode
   LDX   #$FF         ; empty stack
   TXS            ; set the stack
Then it goes on to copy some vectors, provide a signon message and allow you to select cold or warm start. If you decide to omit parts of the min_mon wrapper you must know what you are doing. A monitor should start EHBasic by JMP RES_Vec, not by jumping to EHBasic directly. Once EHBasic is running it is save to assume the D-flag is clear. It is only set and cleared again in HEX$(). Custom interrupt vectors should have CLD if ADC or SBC is to be used.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5


Top
 Profile  
Reply with quote  
PostPosted: Mon Oct 23, 2017 3:26 pm 
Offline

Joined: Sun Apr 16, 2017 2:35 am
Posts: 34
I know we're a few months removed here, so I apologize for the bad form. I had to pack up and move and have only recently got the thing set up again. I didn't think I should make a whole new post just to tackle the same issue. I've tried all of the suggestions to no avail. I've made a single stepper and will step through the program.

At any rate, I've noticed anybody using EHBasic hasn't used the memory map in the first example of the primer (none that I could find, anyway). Is there some sort of issue with EHBasic and this memory map setup? I was under the impression that EHBasic was pretty flexible with this.

So to recap. It runs, counts the memory available correctly, and can even write and list programs in memory. However, when you do anything such as "PRINT 2+2" everything dims and restarts. A regular PRINT statement with nothing after it works correctly. I've also used two different RAM chips, both brand new with no change.

I've also changed over to using the ACIA to drive my display, just because it was easier for the time being. With the Tellymate Tiny I have a nice monitor to use as a display. Same symptoms even with that as the display.

EDIT: Clarification


Top
 Profile  
Reply with quote  
PostPosted: Wed May 23, 2018 3:00 am 
Offline

Joined: Sun Apr 16, 2017 2:35 am
Posts: 34
After a marriage and finally settling into a new place, I've FINALLY had time to sit down and debug this thing.

So everyone, I've finally found the problem.

I narrowed it down based on some other strange behavior on my monitor program. I noticed when I put code in certain locations in the monitor's code, it would crash the computer, but if I put that code at the end of the monitor and just did a JSR do it, it would work.

It was a defective 65C02!

I borrowed the one from my Apple IIe, since it is out of commission for the time being...lo and behold EHBasic runs perfectly now!

This board went through so many revisions, starting from when I didn't have ANY clue what I was doing. It is likely in those days that I connected it wrong and broke something.

Hopefully this helps anyone else. If EHBasic seems like it should work but just refuses...it could be the processor!


Top
 Profile  
Reply with quote  
PostPosted: Wed May 23, 2018 3:30 am 
Offline

Joined: Sat Dec 13, 2003 3:37 pm
Posts: 1004
NickH93 wrote:
After a marriage and finally settling into a new place

Going on the crass assumption that it's your marriage, congratulations!


Top
 Profile  
Reply with quote  
PostPosted: Wed May 23, 2018 3:33 am 
Offline

Joined: Sun Apr 16, 2017 2:35 am
Posts: 34
whartung wrote:
NickH93 wrote:
After a marriage and finally settling into a new place

Going on the crass assumption that it's your marriage, congratulations!


Ha, I should have clarified, yes I got married.

Thanks so much!


Top
 Profile  
Reply with quote  
PostPosted: Fri May 25, 2018 4:39 am 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3366
Location: Ontario, Canada
NickH93 wrote:
It was a defective 65C02! [...]
I borrowed the one from my Apple IIe [...] and behold EHBasic runs perfectly now!
If you haven't already, can I suggest you try reinstalling the original CPU to verify that the problem returns? Crap happens, and it's possible to be misled. Just one example: I've seen cases where a problem disappeared after removing then reinserting the very same IC -- in other words not a swap. But all the fussing around disturbed something. Maybe removed some tarnish from the socket, although that's not the only possibility. :roll:

J :)

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


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 51 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 22 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: