Jump to content
bbking67

The PBI Device We Need

Recommended Posts

it might require one more bodge wire or 2, I forget exactly but I thought there was something to change to go full speed. 57.6 ~ wasn't going to be a problem though...

Share this post


Link to post
Share on other sites
2 hours ago, _The Doctor__ said:

it might require one more bodge wire or 2, I forget exactly but I thought there was something to change to go full speed. 57.6 ~ wasn't going to be a problem though...

Yes, this is from the documentation for the W65C51 and means rewiring of the crystal would be required to use it as the external clock signal. Doing so would also disable the internal baud rate generator unless it was done with a switch that allows both settings.

Quote

Crystal Pins (XTLI, XTLO)

These pins are normally directly connected to the external crystal (1.8432 MHz) to derive the various
baud rates. Alternatively, an externally generated clock can drive the XTLI pin, in which case the XTLO
pin must float. XTLI is the input pin for the transmit clock.

 

Edited by BillC

Share this post


Link to post
Share on other sites
On 1/11/2021 at 2:30 AM, Faicuai said:

With STOCK hardware, the XEP80 will dump FastBasic's latest manual (ENTIRE 45+ Kbytes) in 1m:17secs, via TYPE command on OSS dos, and in 1m:37secs under SDX.

Not the same file (I do not have the TXT file you are speaking about), but I got a 43k TXT file and TYPE under SDX goes for 1 min 10.40 secs. So it seems that VBXE drivers are faster (despite much memory banking involved and despite that they also setup color information, so the data throughput is twice as large).

Edited by drac030
  • Like 1

Share this post


Link to post
Share on other sites
12 hours ago, Mathy said:

Which part of the conditions of the HW contest should be changed in your opinion and why?

 

How I would change the rules of the hardware contest:

  • no jury anymore - targeted audience are the users, they should decide what makes sense for them or not.
    (There are several other reasons, why I don't like the idea of a jury, but this would be to long now.)
  • no minimum number of entries - just let the contest happen. A bet on the future or moving an entry to the
    next year isn't fun and likely produce problems (as we learned)
  • users can give 1 to 10 points for an entry, this is the calculation base for the prize money.
    If there are eg. € 1000,- in the contest and 10 users voted (so maximum accumulated points would be 100,
    a point equals € 10,-). If all users gave only one point for a "low quality" single entry,
    the participant still gets €100,-, but €900,- are "saved" for the club, while only one low-quality entry took part.
  • no hardware in development category - don't vote for something that could be (which is even more
    abstract or hard to imagine for the members) and may never will happen.
  • participants get the expenses for one unit + P&P back from Abbuc. This will not only
    be send to the "Hardware Resort" for inspection, but will take part in a lottery, where every voter is able to win it.
    This should encourage users to vote and somewhat uncovers real costs for a single unit.
    Important: The rank a voter gave to a hardware doesn't necessarily match the unit he wins.
    This should prevent ranking a costly hardware up to win and then, while having no personal use,
    resell it. The hardware with the best usage scenario and not the most expensive one should win.

(As the number of votes are also not that high for the software contest, IMHO some kind of benefit for voters
should also be introduced there. (To put participants voting for their own entries into perspective.))

...and, do you like my proposal that much, as you liked already my rule change proposal for the software contest back then? 😉

Share this post


Link to post
Share on other sites
8 hours ago, drac030 said:

Not the same file (I do not have the TXT file you are speaking about), but I got a 43k TXT file and TYPE under SDX goes for 1 min 10.40 secs. So it seems that VBXE drivers are faster (despite much memory banking involved and despite that they also setup color information, so the data throughput is twice as large).

I will do it for you:

 

Dumping FastBasic's manual (46,815 bytes on its latest version) from SDX's prompt (simple "type" command), yields:

 

1. VBXE (1.06 SDX drivers, tested on Altirra v4.00-t24): 1m:14secs

2. XEP80 ultra drivers (v07, latest I have seen): 1m:37secs.

 

It goes to show that, with only the assistance of 6502 and PIA, the XEP80 is no "slow-as-molasses drag" as suggested in prior posts. And I already got solid evidence that, with the Motorola PIAs, it could go even faster.

 

When I have a chance, I will test on Bit3 card (need to find some time to setup my test-bed 800, as Incognito is essentially incompatible with it). The cool thing with Bit3 is that it does not need PBI at all, and relies entirely on the 800's architecture.

Edited by Faicuai
  • Like 2

Share this post


Link to post
Share on other sites
1 hour ago, Faicuai said:

Dumping FastBasic's manual (46,815 bytes on its latest version)

Can you link to the file so @drac030 can try this themselves as I suspect that will be on real h/w?

Share this post


Link to post
Share on other sites

Interesting that you mention the Motorola PIA's @Faicuaias that what I plan on using in a dual-PIA board that I'm going to install in my 800. This is not my design, but I'm in a conversation with the person who is designing them. But I'm not sure if it's my place to say anything or not. So it's up to him to go into further detail, should he read this thread and post. I was going to post an image, but on second thought, even though I think it can be seen freely to the public in the other thread on another site, I don't think it's my place. I was going to do my own DIY piggy-back of PIA's like the old DIY dual-Pokey's until he mentioned his project. I don't know if he intends to bring it all public or not, or if this is just something for a few people, considering how niche it is anway.

 

 

Share this post


Link to post
Share on other sites
3 minutes ago, Gunstar said:

Interesting that you mention the Motorola PIA's @Faicuaias that what I plan on using in a dual-PIA board that I'm going to install in my 800. This is not my design, but I'm in a conversation with the person who is designing them. But I'm not sure if it's my place to say anything or not. So it's up to him to go into further detail, should he read this thread and post. I was going to post an image, but on second thought, even though I think it can be seen freely to the public in the other thread on another site, I don't think it's my place. I was going to do my own DIY piggy-back of PIA's like the old DIY dual-Pokey's until he mentioned his project. I don't know if he intends to bring it all public or not, or if this is just something for a few people, considering how niche it is anway.

 

 

He's welcome to lurk-and-read... ;-)

 

Some prior scope-checks during testing of XEP's (Avery) Ultra drivers (v06 and v07)... You can clearly see how the Moto's response appears faster and more accurate under higher frequencies:

 

 

Share this post


Link to post
Share on other sites
7 minutes ago, Wrathchild said:

Can you link to the file so @drac030 can try this themselves as I suspect that will be on real h/w?

It's on the last-seen .ATR FastBasic package... MOVE the files first to HD partition (DO NOT type from virtually or SIO mounted .ATR !):

 

fastbasic-v4.4.atr

  • Like 1

Share this post


Link to post
Share on other sites

On real h/w it is about the same (no surprise, Altirra is pretty accurate): 1 min 14.46 secs.

 

On Rapidus: 0 min 35.24 secs (default mode) or 0 min 31.66 secs (fast rd/wr mode).

 

If one asks, why so slow: VBXE is on the slow side of the bus, and so is the SDX cartridge.

  • Like 1

Share this post


Link to post
Share on other sites
17 hours ago, BillC said:

Yes, this is from the documentation for the W65C51 and means rewiring of the crystal would be required to use it as the external clock signal. Doing so would also disable the internal baud rate generator unless it was done with a switch that allows both settings.

Total bullshit, I'm afraid..

All that is required is setting the register to 0..

 

Like I said before, it's done pretty commonly on apple IIc, apple super serial cards, etc.. for fast serial transfer of disk images on the apple II.. And there's no switch involved.. And on those implementations the chip is also clocked at 1.8432mhz..  Its pretty standard..  

 

 

 

Share this post


Link to post
Share on other sites
6 hours ago, Faicuai said:

It goes to show that, with only the assistance of 6502 and PIA, the XEP80 is no "slow-as-molasses drag" as suggested in prior posts. And I already got solid evidence that, with the Motorola PIAs, it could go even faster.

 

Ok, enough. Load up the Action! editor, and load a couple pages of text. Page Down. Instantaneous. Now copy your wall of text to the XEP-80 E:, see how long it takes to go from top of screen to bottom. Not instantaneous. As a DOS CLI display, XEP-80 is fine. As a paginating display. it's SLOW. Now if there is some secret mode that grants you access to the memory in the XEP-80 or otherwise lets it paginate at lightspeed, then I might change my mind. For *full screen code editing* an XEP-80 is not a good choice, IMNSHO. For the MAC/65 editor, I'm sure it's swell, but I quit using that editor 15 years ago.

Share this post


Link to post
Share on other sites
10 hours ago, Irgendwer said:

How I would change the rules of the hardware contest:

  • no jury anymore - targeted audience are the users, they should decide what makes sense for them or not.
    (There are several other reasons, why I don't like the idea of a jury, but this would be to long now.)
  • no minimum number of entries - just let the contest happen. A bet on the future or moving an entry to the
    next year isn't fun and likely produce problems (as we learned)
  • users can give 1 to 10 points for an entry, this is the calculation base for the prize money.
    If there are eg. € 1000,- in the contest and 10 users voted (so maximum accumulated points would be 100,
    a point equals € 10,-). If all users gave only one point for a "low quality" single entry,
    the participant still gets €100,-, but €900,- are "saved" for the club, while only one low-quality entry took part.
  • no hardware in development category - don't vote for something that could be (which is even more
    abstract or hard to imagine for the members) and may never will happen.
  • participants get the expenses for one unit + P&P back from Abbuc. This will not only
    be send to the "Hardware Resort" for inspection, but will take part in a lottery, where every voter is able to win it.
    This should encourage users to vote and somewhat uncovers real costs for a single unit.
    Important: The rank a voter gave to a hardware doesn't necessarily match the unit he wins.
    This should prevent ranking a costly hardware up to win and then, while having no personal use,
    resell it. The hardware with the best usage scenario and not the most expensive one should win.

(As the number of votes are also not that high for the software contest, IMHO some kind of benefit for voters
should also be introduced there. (To put participants voting for their own entries into perspective.))

...and, do you like my proposal that much, as you liked already my rule change proposal for the software contest back then? 😉

Hello Irgendwer

 

IMHO not a lot of people voted in the software contest because you had to vote online  There was no general assembly this year, so you couldn't hand in your voting sheet personally.

 

Judging software is a lot easier than judging hardware, because it's fairly easy to copy a piece of software and send it to a lot of people.  So lots of people can test the software.  You can not easily copy hardware.  So most people will have to go by what others tell them about the hardware.  Not everybody is good at telling other people about stuff (s)he made.  And to talk about somebody else's hardware, you need to understand the hardware and maybe it's advantages over similar hardware.  That's why the hardware contest has a jury, which consists mostly of hardware guys.  If you have a piece of software, you can try it and eventually find out how to use it.  You can't experiment with a piece of hardware that you do not have.  The jury system might have its drawbacks, but at the moment, it's the best we have.  At some point of time, we might come up with a better idea, but up till then...

 

If a hardware developer needs money to develop something, he can always contact ABBUC for help.  It's been like that under Wolfgang and I'm sure it will be under Sascha.

 

Sincerely

 

Mathy

 

Share this post


Link to post
Share on other sites
1 hour ago, Alfred said:

Ok, enough. Load up the Action! editor, and load a couple pages of text. Page Down. Instantaneous. Now copy your wall of text to the XEP-80 E:, see how long it takes to go from top of screen to bottom. Not instantaneous. As a DOS CLI display, XEP-80 is fine. As a paginating display. it's SLOW. Now if there is some secret mode that grants you access to the memory in the XEP-80 or otherwise lets it paginate at lightspeed, then I might change my mind. For *full screen code editing* an XEP-80 is not a good choice, IMNSHO. For the MAC/65 editor, I'm sure it's swell, but I quit using that editor 15 years ago.

There seems to be a "confuzion", here.

 

Been working with Action! for sometime now (LOVE IT, btw!), and I must warn you that it has its own Editor-driver, essentially incompatible with anything E: or S: compliant... and that includes the XEP80 and and VBXE (unless there is a specific driver written only for Action, for any of these two solutions). It can even divide the main screen in independent sub-windows (!)

 

No 80-col SW-based (or HW-based) that I know or have seen for the Atari, is actually "instantaneous". Not even native 40-col mode driven through E:, which requires sw-acceleration either in ROM or as external driver, such as SDX's QuickED. 

 

The only thing I know of instantaneous is blasting characters directly at the text-buffer where Antic (and its display list) pick-up data to be rendered on the screen (e.g. poking single bytes directly at $58/$59 vector with E: OS-driver open).

 

I presume this would be the same challenge, anyway, for any other solution connected directly on the system-bus (Like the 800's Bit3 inserted on Slot-3) or a PBI-attached solution. To be compatible, it will need to meet the OS's driver-model, or then use proprietary driving-SW, memory I/O ranges, different screen-buffer vectors, etc.

Edited by Faicuai

Share this post


Link to post
Share on other sites

Geeze, I'm well aware of how the Action! editor works. I'm merely pointing out that you insisting that the XEP80 is as fast as a local memory display for editing (like the Action! editor) is simply not true. For full screen editing without delay, the only choices I see today are Antic or VBXE. E: solutions are not viable to me, no matter how fast, they don't beat a memory mapped display, period. Yes, Avery's custom XEP driver is fast (I looked at it the other night) but MAC/65 doesn't paginate anywhere near as fast using it as the Action! editor does with its memory mapped display. Yes, that fast driver isn't molasses compared to the stock E: but compared to a memory mapped display, it is.

  • Like 1

Share this post


Link to post
Share on other sites
11 minutes ago, Alfred said:

Geeze, I'm well aware of how the Action! editor works. I'm merely pointing out that you insisting that the XEP80 is as fast as a local memory display for editing (like the Action! editor) is simply not true. For full screen editing without delay, the only choices I see today are Antic or VBXE. E: solutions are not viable to me, no matter how fast, they don't beat a memory mapped display, period. Yes, Avery's custom XEP driver is fast (I looked at it the other night) but MAC/65 doesn't paginate anywhere near as fast using it as the Action! editor does with its memory mapped display. Yes, that fast driver isn't molasses compared to the stock E: but compared to a memory mapped display, it is.

Fast as local memory display? I think we are both on the same page, there, as that is (obviously) not the case.

 

I was specifically addressing this comment, though: "Watching the XEP-80 scroll a full screen of 80 column text is like watching paint dry."

 

Just posted evidence above (vis-a-vis VBXE performing the same task on same environment) and that it is NOT the case, and much less with latest drivers. 

 

Hope it is clear, now.

Share this post


Link to post
Share on other sites
3 minutes ago, Faicuai said:

I was specifically addressing this comment, though: "Watching the XEP-80 scroll a full screen of 80 column text is like watching paint dry."

 

No, it is, when the comparison is with a memory mapped display. Perhaps, I should amend that to all E: devices which scroll, watching them redraw a full display 40 or 80 columns is like watching paint dry. Apparently we differ in our sense of the passing of time. I have a near zero tolerance for many things these days, and non-zero screen redraw time is certainly one of them, which is why when I get some time I am porting that damned Action! editor to the VBXE. Either that or my port of SPF/PC, but I haven't solved the NewLine/Enter key problem for that one.

Share this post


Link to post
Share on other sites

I'd honestly LOVE for somebody to take what we've done for #FujiNet, and adapt it for PBI. It may take some creative work, but as has been proven in another thread, while the #FujiNet firmware code does use a LOT of ESP-IDF, it can be ported off the ESP32 (and has been shown running on x86), so even if it's not feasible to glue an ESP32 onto an 8-bit data bus (I think it is, it'll need a competent hardware engineer to work out the glue), it can be put on something else, while maintaining the API we've managed to create.

 

The license for #FujiNet is GPL 3.0, which, we interpret as:

 

* STEAL IT

* BUT ALLOW OTHERS TO STEAL WHAT YOU ADD TO IT, TOO. :)

 

(The 3.0 version of the license states this even more explicitly)

 

-Thom

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, tschak909 said:

I'd honestly LOVE for somebody to take what we've done for #FujiNet, and adapt it for PBI.

There are only a handful of people that A) have the know how to do this, and B) would be willing to do it essentially for free (not a closed source). You'll get a lot of people promising things, and seeming to want to really make it happen, but in the end not too many will actually deliver on these promises. Sorry to be somewhat cynical, but this is what I've seen on AA and elsewhere. We do however have a few developers like yourself, your team, and also @flashjazzcat that do incredibly wonderful things without worrying about the money. And there are a few more players just like this on AA, but most of them already have there time allocated to other projects.

 

With all that said, I really think that FujiNet as it stands makes the most sense. It's very universal in nature, doesn't interfere with the Atari's bus, and is pretty forgiving from an interface point of view. A PBI version would not be universal, leaving out several machines, and can potentially cause system bus loading that interferes with other processes. it also requires entirely different interfaces dependent upon whether it's meant for an XL or an XE, with the XE also requiring a cartridge port augment due to the original port being consumed by the interface. Yes this has been accommodated in a few other PBI type devices, but in some cases you end up with something ungainly hanging off the back of the unit.If it were approached more like the U1MB as an internal upgrade, then it might be better. Although it will be competing for space with the U1MB as well as other internal upgrades.

Share this post


Link to post
Share on other sites

I know. Have contributed to free software projects for roughly 30 years, I completely understand how people come and go. My job is to make the house available.

 

-Thom

 

Share this post


Link to post
Share on other sites
6 hours ago, Faicuai said:

Just posted evidence above (vis-a-vis VBXE performing the same task on same environment)

What you are comparing there is mostly the E: editor at work. Now go and run on XEP-80 something like Sparta Commander - which also uses the drivers, but low level ones, bypassing the E:. There even were plans to prepare such a driver for XEP, but it was not done. I guess however that watching Sparta Commander redraw its panels on XEP would indeed be like watching paint dry.

Share this post


Link to post
Share on other sites
10 hours ago, tschak909 said:

I'd honestly LOVE for somebody to take what we've done for #FujiNet, and adapt it for PBI. It may take some creative work, but as has been proven in another thread, while the #FujiNet firmware code does use a LOT of ESP-IDF, it can be ported off the ESP32 (and has been shown running on x86), so even if it's not feasible to glue an ESP32 onto an 8-bit data bus (I think it is, it'll need a competent hardware engineer to work out the glue), it can be put on something else, while maintaining the API we've managed to create.

 

The license for #FujiNet is GPL 3.0, which, we interpret as:

 

* STEAL IT

* BUT ALLOW OTHERS TO STEAL WHAT YOU ADD TO IT, TOO. :)

 

(The 3.0 version of the license states this even more explicitly)

 

-Thom

I think so too. The fact that there's no hardware interface is a problem. If someone could make some kind of interface where, for instance, the IO pins on an SBC could directly talk to the PBI...that would be helpful. Something kind of general purpose. I don't know much about hardware, so maybe it's a dumb ask, but if there were such a thing I'd buy one and see what I could do.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...