Trouble with small project
cbmeeks
Posts: 634
in Propeller 1
I haven't been doing any spin/pasm in a long while.
This weekend I decided to work on a little project of mine. Long story short, I've connected a P1 to a VIC-20 in order to read the data bus.
The VIC-20 has an I/O line that goes low when a certain address is accessed ($9800 in this case).
I have the Propeller connected as follows:
VIC-20 data bus D7:D0 connected to P7:P0.
VIC-20 I/O2 select connected to P9
For this simple example, I just want to snag what is on the data bus and send it to the serial port.
I realize that Spin isn't going to be fast enough for this. I thought once I got *SOMETHING* showing up on the terminal, I would optimize it with PASM.
However, I get nothing no matter what I do.
I wrote a short program on the VIC to poke values into the correct address.
Also, I have an LED on P15 just to prove the Propeller is actually running.
Any ideas what I could be doing wrong?
HW.spin
IO.sping
CBM.spin (main program)
This weekend I decided to work on a little project of mine. Long story short, I've connected a P1 to a VIC-20 in order to read the data bus.
The VIC-20 has an I/O line that goes low when a certain address is accessed ($9800 in this case).
I have the Propeller connected as follows:
VIC-20 data bus D7:D0 connected to P7:P0.
VIC-20 I/O2 select connected to P9
For this simple example, I just want to snag what is on the data bus and send it to the serial port.
I realize that Spin isn't going to be fast enough for this. I thought once I got *SOMETHING* showing up on the terminal, I would optimize it with PASM.
However, I get nothing no matter what I do.
I wrote a short program on the VIC to poke values into the correct address.
Also, I have an LED on P15 just to prove the Propeller is actually running.
Any ideas what I could be doing wrong?
HW.spin
CON '========================================================================== ' Pin definitions '========================================================================== #0 ' Start enumeration from 0 ' P0 pin_D0 ' \ pin_D1 ' | pin_D2 ' | pin_D3 ' | [In/Out] Data bus of the 6502 ' P4 ' | pin_D4 ' | pin_D5 ' | pin_D6 ' | pin_D7 ' / 'P8 pin_VRW ' VIC R/W pin_IO2 ' I/O2 $9800-$9BFF: 1 KB, I/O Expansion 2, accessed by I/O2 line pin_IO3 ' I/O3 $9C00-$9FFF: 1 KB, I/O Expansion 3, accessed by I/O3 line '========================================================================== ' BitMasks '========================================================================== ' Data bus con_mask_DATA = (|<pin_D0) | (|<pin_D1) | (|<pin_D2) | (|<pin_D3) | (|<pin_D4) | (|<pin_D5) | (|<pin_D6) | (|<pin_D7) PUB dummy ' Every module must have at least one PUB function otherwise it won't compile CON
IO.sping
OBJ
hw: "hardware"
pst: "FullDuplexSerial"
PUB Start | db
pst.start(31, 30, 0, 115_200)
repeat
waitpne mask_IO2, mask_IO2
pst.dec(INA[7..0])
pst.tx(13)
DAT
mask_IO2 long (|< hw#pin_IO2)
CBM.spin (main program)
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
OBJ
io: "IO"
PUB main | i
waitcnt(cnt + 5_000_000) ' small delay for PLL to warm up.
' Data bus to input initially
DIRA := %00000000_00000000_10000000_00000000
io.Start
repeat
outa[15] := 1
waitcnt(cnt + 5_000_000)
outa[15] := 0
waitcnt(cnt + 5_000_000)
Comments
waitpne mask_IO2, mask_IO2 pst.dec(INA[7..0])How is this ever going to capture anything? By the time the pst.dec reads the inputs the data has been long gone. You need to latch that information immediately after waitpne but this really needs to be in PASM and then Spin will simply detect an update and report it but don't expect it to handle any realtime event unless it is very slow.
Do you need help with some PASM? It would only take a few lines of code to WAITPNE then read the ports and write it to a hub variable.
btw, High level Tachyon should be able to capture this without resorting to PASM. How long is the I/O select? Come to think of it I already have a Tachyon application called SPLAT that works like a logic analyzer capturing port pins and reports back to an ANSI compatible terminal emulator.
For the data bus (bi-directional), I am using some level converters. For the two control pins, I have a 4.6K resistor in series and they are input only.
I would love some help. Something to get me started. Like I said, I've been out of the Propeller loop (no pun) for quite some time.
I'm not familiar with your Tachyon project but I will certainly check it out.
I realize what I'm doing may be trivial to you guys but I've been out of sorts for a while and I'm slowly getting back into it.
I really do want to do this in PASM because the ultimate plan is to get my VIC-20 to use a SIDCog so sending data to/from it is essential.
Thanks again for any help.
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 IO2PIN = 9 OBJ pst: "FullDuplexSerial" VAR long vicdata PUB main | i dira := 1<<15 'LED = output cognew(@vicasm,@vicdata) pst.Start(31,30,0,115200) repeat vicdata := -1 repeat while vicdata < 0 'wait for data from PASM cog pst.dec(vicdata) 'show on Terminal pst.tx(13) outa[15] ^= 1 'toggle LED DAT org 0 vicasm waitpne IO2,IO2 'wait until IO2 low mov tmp,INA 'read databus and tmp,#$FF 'only bits 7..0 wrlong tmp,PAR 'write into vicdata var waitpeq IO2,IO2 'wait until IO2 high jmp #vicasm 'loop IO2 long 1<<IO2PIN tmp long 0It sends something if I change the state at pin 9, but that's all I tested.Andy
will not work reliably, 74HCT is needed...
Thank you so much! I will give that a shot this evening....assuming real life doesn't get in the way again. :-) Either way, I will give it a shot and let everyone know.
Thanks!
I have a few of these: https://www.sparkfun.com/products/12009
Which use a few BSS138's.
Schematic to the level converter here: https://cdn.sparkfun.com/datasheets/BreakoutBoards/Logic_Level_Bidirectional.pdf
the other.
I think I meant 74LVC for 5V -> 3.3V conversion, LVC runs from 3.3V but is 5V tolerant on the
inputs. It shouldn't have trouble with TTL levels.
It could also send data back to the 5V system too from the P1 (at 3.3V CMOS output levels) with the same logic family because the output of this logic can be externally held at 5V without a problem when it is tristated which is very convenient.
2x74LVC244A's are well suited to doing this on an 8 bit bus if you have independent read and write strobes.
@rogloh, do you have more details on your project? Sounds interesting.
Last night I was able to get the P1 to display text each time the VIC-20 poked a value. However, it kept showing the same value (152).
At least I have something to work with now.
Thanks
or something)?
Echo waitpeq wrdatstate, wrdatmask mov echodata, ina wrlong echodata, echomailptr jmp #echo wrdatmask long %00000000_00000000_01111011_00000000 wrdatstate long %00000000_00000000_00001010_00000000 ' i echodata long -1 echomailptr long 0I had another cog running Spin code to pick up new values of echodata from LONG[emailptr] which shifted out and printed the bits I wanted.This looks like what I'm looking for!
I am curious, however, why the '-1" for echodata?
Thanks!!
And I was thinking of doing something similar with a TRS Model 102 I have here. I confess I've not done anything with 6502 based systems in over a year outside of the VCF each year here. What sort-of Propeller board are you using for this? Is it any of the available ones? Or did you build it yourself? If you did build it yourself can you share its schematic?
---
erco your robots were seen trying to catch buses in both Union Square (NYC) and Astor Place.
Schematic will come later...right now the madness is in my head and on a breadboard. lol
To be honest, I'm trying to see if the Propeller can act as a memory manager and audio chip for the VIC-20. I'd rather not use CPLD if I can help it. Everything is up in the air and I'm just experimenting for the moment.
I've connected my VIC-20 to a breadboard via a nice breakout board I got on eBay.
If I get anything working this evening, I'll post some pictures.
Great! [Said the tiger]
If its the one I'm thinking of, then your breakout board, is the same ones I saw at VCF one year.
And I'm still thinking of trying out something-of-a-sort with that machine that I mentioned. Meanwhile I'm off to the races with an interesting problem regarding Linux......
Buck Rogers -- my project was a custom circuit board designed to plug into the proprietary bus of an industrial instrument, replacing a primitive UART that is no longer available. I had to make several test boards before arriving at a design that did all the functions I needed.
Was that board our correspondent is using?
You guys are awesome!!
Here is the code that is working:
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 OBJ pst: "FullDuplexSerial" VAR long vicdata PUB main | i waitcnt(cnt + 5_000_000) ' small delay for PLL to warm up. cognew(@vicasm,@vicdata) pst.Start(31,30,0,115200) repeat vicdata := -1 repeat while vicdata < 0 'wait for data from PASM cog pst.dec(vicdata) 'show on Terminal pst.tx(13) DAT org 0 vicasm waitpeq wrdatstate, wrdatmask 'wait until IO2 low mov tmp,INA 'read databus and tmp,#$FF 'only bits 7..0 wrlong tmp,PAR 'write into vicdata var jmp #vicasm 'loop tmp long -1 wrdatmask long %00000000_00000000_00000010_00000000 wrdatstate long %00000000_00000000_00000000_00000000Links to pics included. Once I get some more features going, I will keep everyone posted.
Thanks again!
https://github.com/cbmeeks/public/tree/master/Pics
**EDIT**
Interesting update...
BASIC on the VIC-20 was no problem. Propeller could keep up.
So I decided to write the following asm:
loop inc $9800 jmp loopThe terminal couldn't keep up! So, I haven't done the math. I don't know if the Propeller is too slow. I imagine 115,200 baud just can't keep up. But that's OK. The end-game isn't to capture text like that. It's to control some RAM chips and emulate a SID. I just hope the Propeller can handle that.
Fun fun!
Hi cbmeeks,
yes I have a few more details if you'd like. The key snippet here is the front end schematic that I used to interface to the Z80 data bus which is shown below (ignore the references to 74ls244's as I just used that symbol name in Eagle but the board really has 74lvc244a's fitted). I used WAITPEQ and WAITPNE in a similar way to what has already been mentioned above to wait for bus read or write access.
In my application I basically use an eeZee prop module to intercept some Z80 memory writes and some I/O reads/writes to allow this module to control SD card access, which is intended to replace boot floppies in a CP/M system, and for composite video/VGA purposes.
Intercepting the writes was simple, the tricky part is the I/O reads and getting the P1 output pins to go in and out of tristate at the right time to ensure you never output on the P1 bus using multiple simultaneous drivers. Timing is critical there unless wait states are used which gives you more time to respond to the read. Not sure about the VIC20 timing but on a 3.375MHz Z80, responding to I/O reads is (just) possible without wait states when using a 80Mhz P1 clock which works out quite nicely. In fact it worked out so well that I am now making another board at the moment to support color video and sprites too and better sound.
Roger
I only have 74HCT244's in my parts bin. Not sure if that would work.
But I like the idea of using them as level shifters.
**EDIT**
No, HCT version won't work because they're not low voltage....I'll see about ordering some LVC's.
This is to be expected. Both Spin and BASIC are one to two orders of magnitude slower than assembly languge because of the overhead of interpreting the tokens and calling appropriate handlers to do things that are often a single instruction in assembly. That INC loop is probably cycling a couple hundred thousand times a second on a 1-MHz 6502. In practice you won't need transfer rates that fast because your application will determine the necessary throughput.
Most Propeller instructions take 4 clocks, so at 80 MHz that's 20 million per second. But Spin is about 50 times slower so you figure around 500,000 tokens per second. This is why Spin isn't quite fast enough to grab a byte that's only on the data bus for a one-microsecond 6502 clock cycle. But Spin should be fast enough for most real application tasks, because in a real application the 6502 has to do other stuff before cycling around and sending you a new value.
One way to demonstrate this would be to have your service loop update a mailbox of both a count of new readings and the value, and have another cog periodically transmit those two values say ten times a second. If you're keeping up, you will see the count and value tracking, but if you're missing readings the count will lose ground to the value passed by the VIC. That way you aren't trying to send every single new value out the serial port, which is an order of magnitude too slow to keep up.
(Must stay in character on this forum.)
Basically you're right. I remember some interesting activities on both an Apple 2Plus and then on an Apple 2E where BASIC programs that did stuff on the graphics screen spun on a specific speed.
But the same activities in Assembler on both spun as much as 55 percent faster.
At that point in time I was also looking at how to connect either of them to existing controller designs, and also the same for the widget that you own cbmeeks.
Which of course was after buying a book which described the thing's anatomy, the book did help with the efforts needed to do better programming on it, this was working with an individual I knew.
Now as for teaching a Prop to walk all over a TRS-80 Model 102. and borrowing your circuit design rogloh if at all possible, I'll think about it.
Beat it that time, got a stent, everything seems under control, but as far as I know my ischemia is still silent. I check the BP often.
Oh and I get paid to design this stuff with Propellers. The Propeller made manufacturing custom controllers possible for my company. I would not have tried it with any other product, and insisted to my superiors that it was impossible until I came across an article about the YBOX2.
Hello!
I'm not. Just the way I write sometimes. And as it happens, I found out about that little devil, via two channels. The earlier version of the forum, from Mike Green, and Limor herself. (Via her site.)
I'd also been tracking the Propeller development phases via the earlier forum, and of course here for quite sometime. But that effort is definitely the tiger's stripes. It's an amazing application.
And I'm still wondering if the YBOX2 firmware can be run on a Quickstart wearing the Ethernet card. Of course since the YBOX2 also does video out it would also be quite step......