INA syntax in spin2

ke4pjw · 2021-01-04 05:20

I have looked through the language reference and don't understand why why this does not compile.

dbus := INA[0..7]

I want to read p0-p7 into dbus but get the error that it is expecting a ] where .. is.

What am I doing wrong? Is there a more complete spin2 reference than this https://docs.google.com/document/d/16qVkmA6Co5fUNKJHF6pBfGfDupuRwDtf-wyieh_fbqw/edit#heading=h.nagbjtem5ytb

As always, thanks in advance.
--Terry

Capt. Quirk · 2021-01-04 06:22

I asked a similar question

In the P1, we could do this:
outa[MSB..LSB] := value
dira[MSB..LSB] := %1111
In the P2, we do it like this:
pinwrite(LSB addpins (MSB-LSB), value)

There is a caveat, however. In the P1, we can also do this:
outa[LSB..MSB] := value
...which will reverse the output order of the lower four bits in value. How can we do this in the P2?
pinwrite(LSB addpins (MSB-LSB), value rev (MSB-LSB))

dbus := INA[0..7] == Pinread(0 addpins 7, dbus rev 7)
Or
dbus := INA[7..0] == Pinread(0 addpins 7, dbus)

Bill M.

ke4pjw · 2021-01-04 07:12

Ah, got it. Thank you sir! The last time I worked with my P2 there was only pnut and what is now flexgui. I need to work with this thing more than once a year!

JonnyMac · 2021-01-04 14:18

Do not use P1 syntax for IO on the P2 -- it's a problem. Use the built in pinxxxx() functions. In your case -- with hardwired pins:

  dbus := pinread(0 addpins 7)

Better form is to create a constant name...

CON

  DATA_BUS = 0 addpins 7

... so you can do things like this:

  pinfloat(DATA_BUS)
  dbus := pinread(DATA_BUS)

If the bus is bi-directional you can write to it, too:

  pinwrite(DATA_BUS, value)

-- just make sure you use pinfloat() before the next read. Any function that writes to IO will set the pin(s) to output mode. The pinread() function does not set the pin(s) to input (this lets you read the current state of your outputs on pins).

ke4pjw · 2021-01-04 18:59

Thanks Jon! I figured the syntax once once I knew what I was looking for in the docs.

Also, as an OT comment, I absolutely *LOVE* the ansi_vgatext_demo! I have not thought about ANSI escape sequences in years. It's perfect for using as a debug output! Thank you for all of your work!

JonnyMac · 2021-01-04 23:46

Well, thank you, but ansi_vgatext_demo is not my doing. I wrote jm_ansi.spin2 for ANSI output to standard terminals (e.g., PuTTY).

ke4pjw · 2021-01-05 02:41

Ok, I am banging my head against the wall. I must be doing something stupid

If I *ONLY* read the apins, I see random addresses displayed as expected from abus.
If I read apins and dpins, then the last octet of abus always equals dbus, and it is always 03.
If I read apins, dpins, and cpins, the first octet of abus is always random, the last octet of abus is 03, as is dbus and cbus.

What am I doing wrong. This is driving me crazy!

CON
  PINBASE = 48

  _clkfreq = 250_000_000 


  dpins = 0 addpins 7  ' CoCo Databus pins
  apins = 8 addpins 15 ' CoCo Addressbus pins
  cpins = 24 addpins 1 ' CoCo Clock pins

DAT

abus word
dbus byte
cbus byte 

OBJ
   scrn: "ansi"



PUB runtext() | n
pinfloat(dpins)
pinfloat(apins)
pinfloat(cpins)

scrn.start(PINBASE)
scrn.str(string(27, "[1;1H"))
scrn.str(string(27, "[0J"))

repeat
  dbus := Pinread(dpins)
  abus := Pinread(apins)
  cbus := Pinread(cpins)
  scrn.str(string(27, "[1;1H"))
  scrn.nl()
  scrn.str(string("Address bus:"))
  scrn.hex(abus,0)
  scrn.nl()
  scrn.str(string("Data bus:"))
  scrn.hex(dbus,0)
  scrn.nl()
  scrn.str(string("Clock:"))
  scrn.hex(cbus,0)

Ariba · 2021-01-05 03:01

You can try to read the whole port at once and separate the buses later:

  n := INA
  cbus := n.[25..24]
  abus := n.[23..8]
  dbus := n.[7..0]

Andy

ke4pjw · 2021-01-05 03:30

Ariba wrote: »
You can try to read the whole port at once and separate the buses later:
  n := INA
  cbus := n.[25..24]
  abus := n.[23..8]
  dbus := n.[7..0]
Andy

Similar results, except it is not 03. It is random but all three are the same.

Various configurations yield different results based on the order I perform the read. Something is not right, If I read only one of the three, it performs as expected.

Either my hardware is bad, but it works as expected when only reading one set of pins, or this is a compiler issue. I will try this on my P2 Edge board and see if I get similar results without ever attaching the pins to my hardware.

ke4pjw · 2021-01-05 04:02

Same results on brand new hardware, first time it was ever fired up.

I don't know where to start. My code looks right. Maybe this is a problem in the ANSI display driver and the way it displays hex. Maybe it is a compiler problem. Maybe I don't know enough about what is really going on. I don't see a problem in either my code or the ANSI num or hex methods.

I can say that the last digit of all three outputs follows what the cbus inputs are. I just don't see how that can happening unless this is a hardware glitch or a memory bookeeping problem.

*OR* addpins doesn't work the way I would expect at all.

I don't think I am smart enough to figure it out. I have spent 10 hours on this and the solution eludes me.

ke4pjw · 2021-01-05 05:15

This is starting to look like a problem with the ansi.spin2 library. I am going to use Smart Serial and ers_fmt to see if I get the same result.

msrobots · 2021-01-05 05:32

maybe the hex out expects a long instead of bytes?

try making abus and dbus longs also...

Mike

ke4pjw · 2021-01-05 05:37

There appears to be an off by 1 or 2 when working with words and bytes. I need to sleep and think in this.

ke4pjw · 2021-01-05 05:50

Ok, worse than I thought. Whichever variable gets updated last, updates all. This was found by using longs as the datatype. I have no idea why, This is nuts. Going to bed.

ke4pjw · 2021-01-05 06:07

Here is the problem. Are variable assignments done differently in spin2? Am I losing my mind?

CON
  PINBASE = 48

  _clkfreq = 250_000_000


DAT

a long
d long
c long

OBJ
   scrn: "ansi"



PUB runtext() | n

scrn.start(PINBASE)
scrn.str(string(27, "[1;1H"))
scrn.str(string(27, "[0J"))

  d := $A0
  a := $FFFF
  c := $01


  scrn.str(string(27, "[1;1H"))
  scrn.nl()
  scrn.str(string("Variables are:"))
  scrn.nl()
  scrn.str(string("A Long:"))
  scrn.hex(a,0)
  scrn.nl()
  scrn.str(string("D Long:"))
  scrn.hex(d,0)
  scrn.nl()
  scrn.str(string("C Long:"))
  scrn.hex(c,0)
  scrn.nl()
  scrn.str(string("Variables should be:"))
  scrn.nl()
  scrn.str(string("A Long:"))
  scrn.hex($A0,0)
  scrn.nl()
  scrn.str(string("D Long:"))
  scrn.hex($FFFF,0)
  scrn.nl()
  scrn.str(string("C Long:"))
  scrn.hex($01,0)
  scrn.nl()

msrobots · 2021-01-05 06:23

what is the output of that?

ke4pjw · 2021-01-05 06:42

Variables are:

A Long: 01
D Long: 01
C Long: 01

Variables should be:

A Long: A0
D Long: FFFF
C Long: 01

If you comment out c := $01, then all three are then FFFF.

msrobots · 2021-01-05 07:20

try

DAT

a long 0
d long 0
c long 0

you need to provide a value in dat sections else they refer to the same memory location, maybe word and byte will then work too...

Mike

JonnyMac · 2021-01-05 13:47

Ok, worse than I thought. Whichever variable gets updated last, updates all.

Mike is correct, and you can prove it to yourself with a simple test.

  term.fhex(@a, 8)
  term.tx(13)
  term.fhex(@d, 8)
  term.tx(13)
  term.fhex(@c, 8)
  term.tx(13)

If you're going to declare bytes, words, or longs in a DAT section to be treated like variables they usually need to have an associated value.
There is a use-case for the syntax you're using, as I demonstrated in my Christmas light code.

dat

  Colors        long
'                          rr gg bb xx
  DimRed        long      $0F_00_00_00
  DimWhite      long      $06_06_06_00
  DimGreen      long      $00_0F_00_00

In this case I declared Colors without a value to use like an array to make the code easier to understand. Without a value, Colors has the same address as DimRed.

ke4pjw · 2021-01-05 15:27

Is the requirement that variables declared in the DAT section have a value a spin 2ism or is that a gotcha if declared in the top file?

I know there is plenty of spin 1 code out there where the value is not declared in the DAT section.

Getting hung up on a syntax bugaboo like this is maddening. Thank you everyone for pointing this out!

ke4pjw · 2021-01-05 15:51

Wait, I see my brain fart with clarity now. I confused VAR with DAT. Typically DAT would be at the bottom and VAR at the top.

Again, thanks everyone.

INA syntax in spin2

Comments