6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Thu Nov 14, 2024 5:09 pm

All times are UTC




Post new topic Reply to topic  [ 25 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Mon Feb 08, 2021 6:01 am 
Offline
User avatar

Joined: Mon Feb 01, 2021 1:07 am
Posts: 44
Location: Sydney, Australia
Hi guys,

You might know from my other 65C02 SBC post that I plan on using a ATF22V10C for my glue logic. But to be prudent I'd like to also cater for using a ATF16V8C in case the programmer TL866II Plus I just bought lies. The programmer will be delivery in a month or so (from China).

Below are the details I have put together. If somone would be kind enough to check if I am correct that my memory model won't work with this PLD, thanks.

Memory map
0000-7FFF RAM
8000-FDFF ROM
FE00-FE7F I/O
- FE00-FE0F I/O Device #1 (16 bytes)
- FE10-FE1F I/O Device #2 (16 bytes)
- FE20-FE2F I/O Device #3 (16 bytes)
- FE30-FE3F I/O Device #4 (16 bytes)
- FE40-FE5F I/O Device #5 (32 bytes)
- FE60-FE7F I/O Device #6 (32 bytes)
FE80-FEFF Unallocated - use for external decoding
FF00-FFFF ROM

So, RAM is 32KB, ROM is 32KB-256 bytes, and one page (256 bytes) will be used partially for I/O devices (128 bytes), and the remainder of this space (128 bytes) will be unallocated, for external decoding perhaps.


ATF16V8C - 65C02 wiring
I1 - A15
I2 - A14
I3/PD - A13
I4 - A12
I5 - A11
I6 - A10
I7 - A9
I8 - A8
I9/OE - A7


Memory map with binary addresses
0000-7FFF RAM 0000000000000000 - 0111111111111111
8000-FDFF ROM 1000000000000000 - 1111110111111111
FE00-FE0F IO1 1111111000000000 - 1111111000001111
FE10-FE1F IO2 1111111000010000 - 1111111000011111
FE20-FE2F IO3 1111111000100000 - 1111111000101111
FE30-FE3F IO4 1111111000110000 - 1111111000111111
FE40-FE5F IO5 1111111001000000 - 1111111001011111
FE60-FE7F IO6 1111111001100000 - 1111111001111111
FE80-FEFF N/A 1111111010000000 - 1111111011111111
FF00-FFFF ROM 1111111100000000 - 1111111111111111


Question 1.
How does this memory map look? (Personally I love it). I got this by reading another post (thanks drogon and floobydust).

Question 2.
Is there a need for 32 byte-wide I/O spaces?
I suspect (with no evidence to go on, just a feeling) that 16 byte-wide devices are far more common.
I guess this comes down to my application on what I/O devices I will use. Given this is my first build, I'm unsure what devices I will be using. I'm pretty sure I'll use sensors, e.g. ultrasonics, infrared... to measure my surroundings and process the data.

Question 3.
Since the ATF16V8C has only 9 inputs, this means I can only connect the 65C02's address lines A15..A7 to the PLD. But looking at the binary addresses I require due to the memory model, I would need to connect address lines up to A4 (i.e. A15..A4) for this memory model to work. So I can't using this memory model with the ATF16V8C.
Am I correct here that a memory model to work with this PLD requires addresses above 2^7, i.e. A15..A7?

_________________
Greetings Professor Falken.


Top
 Profile  
Reply with quote  
PostPosted: Mon Feb 08, 2021 2:47 pm 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1385
Well, I opted for a 22V10 for a single glue logic. The extra resources (over the 16V8) provide for qualified Read and Write signals for RAM/ROM and other (non-65XX) I/O devices. I also went with 32-byte wide I/O selects (5 of them). I'm now using a Maxim DS1511 Realtime clock, which does have 32-byte wide addressing, albeit only 18 are actually used.

Be sure to input your defines into WinCUPL and see if it compiles correctly and if the simulator works. I had some really odd issues in WinCUPL with the 16V8. I'm using this on an adapter which breaks up a single 32-byte wide I/O select to drive said 1511 RTC, and a Compact Flash IDE device (both selects) and an upper byte bidirectional latch. Finally got it to compile and sim correctly, but it was an odd one.

Getting the 22V10 to work in WinCUPL wasn't that difficult... so I can only think that there's something odd about the 16V8 with WinCUPL... but again, depending on what you're doing with it, it might change. For reference, here's my code for both:

Code:
Name     Glue3 ;
PartNo   01 ;
Date     10/31/2017 ;
Revision 01 ;
Designer KM ;
Company  Analogue Technologies ;
Assembly SBC2 ;
Location  ;
Device   g22v10 ;

/* *************** INPUT PINS *********************/
PIN 1    = CLK                       ; /*                                 */
PIN 2    = A15                       ; /*                                 */
PIN 3    = A14                       ; /*                                 */
PIN 4    = A13                       ; /*                                 */
PIN 5    = A12                       ; /*                                 */
PIN 6    = A11                       ; /*                                 */
PIN 7    = A10                       ; /*                                 */
PIN 8    = A9                        ; /*                                 */
PIN 9    = A8                        ; /*                                 */
PIN 10   = A7                        ; /*                                 */
PIN 11   = A6                        ; /*                                 */
PIN 13   = A5                        ; /*                                 */
PIN 23   = RW                        ; /*                                 */

/* *************** OUTPUT PINS *********************/
PIN 14   = !IO1                      ; /*                                 */
PIN 15   = !IO2                      ; /*                                 */
PIN 16   = !IO3                      ; /*                                 */
PIN 17   = !IO4                      ; /*                                 */
PIN 18   = !IO5                      ; /*                                 */
PIN 19   = !ROM                      ; /*                                 */
PIN 20   = !RAM                      ; /*                                 */
PIN 21   = !MWR                      ; /*                                 */
PIN 22   = !MRD                      ; /*                                 */

/** Declarations and Intermediate Variable Definitions  **/
FIELD ADDRESS = [A15..0];

RAM = ADDRESS:['h'0000..7FFF];
IO1 = ADDRESS:['h'FE00..FE1F];
IO2 = ADDRESS:['h'FE20..FE3F];
IO3 = ADDRESS:['h'FE40..FE5F];
IO4 = ADDRESS:['h'FE60..FE7F];
IO5 = ADDRESS:['h'FE80..FE9F];
ROM = ADDRESS:['h'8000..FDFF]
        # ADDRESS:['h'FEA0..FFFF];
/** Logic Equations **/
MWR = (CLK & !RW);
MRD = (CLK & RW);



Code:
Name     IDE-RTC ;
PartNo   01 ;
Date     1/04/2020 ;
Revision 01 ;
Designer KM ;
Company  Analogue Technologies ;
Assembly SBC2 ;
Location  ;
Device   G16V8MS ;

/* *************** INPUT PINS *********************/
PIN 1    = CLK                       ; /*                                 */
PIN 2    = A0                        ; /*                                 */
PIN 3    = A1                        ; /*                                 */
PIN 4    = A2                        ; /*                                 */
PIN 5    = A3                        ; /*                                 */
PIN 6    = A4                        ; /*                                 */
PIN 7    = !MRD                      ; /*                                 */
PIN 8    = !MWR                      ; /*                                 */
PIN 9    = !SEL                      ; /*                                 */
PIN 11   = !OC                       ; /*                                 */

/* *************** OUTPUT PINS *********************/
PIN 18   = !UBWE                     ; /*                                 */
PIN 16   = !UBRE                     ; /*                                 */
PIN 19   = UBWL                      ; /*                                 */
PIN 17   = UBRL                      ; /*                                 */
PIN 12   = !CS0                      ; /*                                 */
PIN 13   = !CS1                      ; /*                                 */
PIN 15   = !RTC                      ; /*                                 */
PIN 14   = !HBT                      ; /*                                 */

/** Declarations and Intermediate Variables Definitions **/
FIELD ADDRESS = [A4..0];

RTC = SEL & ADDRESS:['h'00..13];
HBT = SEL & ADDRESS:['h'14..15];
CS1 = SEL & ADDRESS:['h'16..17];
CS0 = SEL & ADDRESS:['h'18..1F];

/** Logic Equations **/

UBWE = MWR & SEL & ADDRESS:['h'18..18];
UBRE = MRD & SEL & ADDRESS:['h'14..14];
UBWL = MWR & SEL & ADDRESS:['h'15..15];
UBRL = MRD & SEL & ADDRESS:['h'18..18];



Peter (cbscpe here) helped with redefining the address ranges, which made things more logical and simpler to grasp, for me at least.

_________________
Regards, KM
https://github.com/floobydust


Top
 Profile  
Reply with quote  
PostPosted: Mon Feb 08, 2021 5:22 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8484
Location: Midwestern USA
Firefox6502 wrote:
You might know from my other 65C02 SBC post that I plan on using a ATF22V10C for my glue logic.

Suggestion: don't create multiple topics for the same project. It makes it harder for casual readers to follow what is going on. Best thing to do is to continue adding a single topic.

Second suggestion is to use code tags around things such as tables, source code, etc., so the code, tables, etc., appears like this:

Code:
Memory map with binary addresses
0000-7FFF RAM 0000000000000000 - 0111111111111111
8000-FDFF ROM 1000000000000000 - 1111110111111111
FE00-FE0F IO1 1111111000000000 - 1111111000001111
FE10-FE1F IO2 1111111000010000 - 1111111000011111
FE20-FE2F IO3 1111111000100000 - 1111111000101111
FE30-FE3F IO4 1111111000110000 - 1111111000111111
FE40-FE5F IO5 1111111001000000 - 1111111001011111
FE60-FE7F IO6 1111111001100000 - 1111111001111111
FE80-FEFF N/A 1111111010000000 - 1111111011111111
FF00-FFFF ROM 1111111100000000 - 1111111111111111

Quote:
But to be prudent I'd like to also cater for using a ATF16V8C in case the programmer TL866II Plus I just bought lies. The programmer will be delivery in a month or so (from China).

I'd stick with the 22V10. You gain more I/O and logic resources with virtually no penalty.

Quote:
Below are the details I have put together. If someone would be kind enough to check if I am correct that my memory model won't work with this PLD, thanks.

Code:
Memory map
0000-7FFF  RAM
8000-FDFF  ROM
FE00-FE7F  I/O
 - FE00-FE0F  I/O Device #1 (16 bytes)
 - FE10-FE1F  I/O Device #2 (16 bytes)
 - FE20-FE2F  I/O Device #3 (16 bytes)
 - FE30-FE3F  I/O Device #4 (16 bytes)
 - FE40-FE5F  I/O Device #5 (32 bytes)
 - FE60-FE7F  I/O Device #6 (32 bytes)
FE80-FEFF  Unallocated - use for external decoding
FF00-FFFF  ROM

So, RAM is 32KB, ROM is 32KB-256 bytes, and one page (256 bytes) will be used partially for I/O devices (128 bytes), and the remainder of this space (128 bytes) will be unallocated, for external decoding perhaps.

Just an opinion, but your I/O decoding is too granular. There is a tendency with beginners to try to use as much of the MPU's address space as possible for fear of "wasting" some. What often happens is the glue logic becomes convoluted and (if discrete) slow. Also, in order to achieve what you are proposing you'd have to hook up 12 of the MPU's 16 address lines to the GAL. Assuming you are using the 22V10, doing so would leave no inputs for anything else, a design decision you may come to regret later on.

Also, what is the purpose of having so much ROM? What all do you plan to put in there? My POC V1.0 and V1.1 units only have 8KB of ROM, yet I was able to fit a complete BIOS in there, along with a machine language monitor and support for SCSI hardware. In my POC V1.2 unit, I decided to give it 12KB of ROM, but that was the result of logic design convenience, not any particular need for more ROM.

Thirdly, there is no design advantage to inserting I/O into the middle of the ROM's address space and thus making ROM non-contiguous. Such a tactic could be useful if you were arranging so you could switch out part of the ROM and expose RAM in the same address space. In this case, however, that isn't possible, and interrupting ROM address space like that only complicates programming the ROM. If it were me, I'd move I/O down so ROM is contiguous to the top of address space and in the process, give yourself more RAM.

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


Last edited by BigDumbDinosaur on Tue Feb 09, 2021 2:50 am, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Mon Feb 08, 2021 5:55 pm 
Offline

Joined: Sat Jan 02, 2016 10:22 am
Posts: 197
The 16V8 has 20 pins, 2 for power, the rest are logic pins. 10 that are input only, 2 that are output only. and 6 that can be used for input an output. It's not going to be able to cope with say 9 inputs and 9 outputs. But say 12 input an 6 output it can cope with. However you need to be aware of the other restriction: there is a maximum of 8 terms per output.

The BBC style embedded IO in the rom and fine grained decoding might be generating more than 8 terms?

If you're not aiming to go super fast, then maybe decode just the I/O block as a whole, then decode finer with a 74xx138 or a 2nd stage 16V8. The 16V8C is avaiable in sub 10ns versions. Chaining 2 isn't going to cause timing issues unless you're running on the ragged edge.

That would give you 3 outputs, ROM, RAM and I/O and 8 inputs A8 to A15.

That woould leave spare pins for PHi and R/W as inputs and qualified !RD and !WR outputs for the memories.


Top
 Profile  
Reply with quote  
PostPosted: Mon Feb 08, 2021 6:07 pm 
Offline
User avatar

Joined: Mon May 12, 2014 6:18 pm
Posts: 365
BigDumbDinosaur wrote:
Firefox6502 wrote:
You might know from my other 65C02 SBC post that I plan on using a ATF22V10C for my glue logic.

Suggestion: don't create multiple topics for the same project. It makes it harder for casual readers to follow what is going on. Best thing to do is to continue adding a single topic.
This might require some clarification. We've brought up creating a Projects forum in the past just for this purpose and it was vetoed each time. The last advice I read was to create a separate topic for each aspect of a project so that things that are relevant to others aren't buried in a monolithic project thread. Garth may want to clarify.

Quote:
I'd stick with the 22V10. You gain more I/O and logic resources with virtually no penalty.
One nice thing about the 16V8 is that it's only 0.3 inches wide, so takes up less than half the space on the board of a 22V10. EDIT: 22V10 is also only 0.3 inches wide.


Last edited by Druzyek on Mon Feb 08, 2021 8:16 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Mon Feb 08, 2021 6:52 pm 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1385
I'm using the ATF22V10... also 0.3 inches wide, so it takes up another 0.2 inches vertically, i.e., 24-pins vs 20-pins.

_________________
Regards, KM
https://github.com/floobydust


Top
 Profile  
Reply with quote  
PostPosted: Mon Feb 08, 2021 8:15 pm 
Offline
User avatar

Joined: Mon May 12, 2014 6:18 pm
Posts: 365
floobydust wrote:
I'm using the ATF22V10... also 0.3 inches wide, so it takes up another 0.2 inches vertically, i.e., 24-pins vs 20-pins.
My mistake! That's right.


Top
 Profile  
Reply with quote  
PostPosted: Tue Feb 09, 2021 2:49 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8484
Location: Midwestern USA
Druzyek wrote:
BigDumbDinosaur wrote:
Suggestion: don't create multiple topics for the same project. It makes it harder for casual readers to follow what is going on. Best thing to do is to continue adding a single topic.

This might require some clarification. We've brought up creating a Projects forum in the past just for this purpose and it was vetoed each time. The last advice I read was to create a separate topic for each aspect of a project so that things that are relevant to others aren't buried in a monolithic project thread. Garth may want to clarify.

While I dimly recall the proposal for setting up a subforum for projects (a build log, if you will), I don't recall anyone suggesting that a new topic be started for each aspect of a project. The idea of starting a topic and adding to it as you go seems to be the preferred way to document a build. If desired, a table of contents could be arranged in the lead post to point to relevant parts of the topic.

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


Top
 Profile  
Reply with quote  
PostPosted: Tue Feb 09, 2021 4:07 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8540
Location: Southern California
Druzyek wrote:
BigDumbDinosaur wrote:
Firefox6502 wrote:
You might know from my other 65C02 SBC post that I plan on using a ATF22V10C for my glue logic.
Suggestion: don't create multiple topics for the same project. It makes it harder for casual readers to follow what is going on. Best thing to do is to continue adding a single topic.
This might require some clarification. We've brought up creating a Projects forum in the past just for this purpose and it was vetoed each time. The last advice I read was to create a separate topic for each aspect of a project so that things that are relevant to others aren't buried in a monolithic project thread. Garth may want to clarify.

It's not always easy to define when it's time to start a new topic. Sometimes it's clear, like when someone started a new topic asking about clock oscillators, and got and answer which raised another question on the same subject so he started another topic, which in turn made him think of yet another question, etc., so there were all these topics about the same thing, for the same part of the same project, and he wasn't even adding links to tie the different portions together. It leads to disjointed clutter.

At the other end, someone might be building hardware, get it going, and then build a language to run on it, which should be in a different topic, even a different section of the forum.

In between these extremes, it might not be so obvious. Just try to make it easy to find and identify topics, and not clutter the forum with multiple topics of the same thing. And of course make the titles relevant. We used to get ones like "Help!" which doesn't give any idea what it's about, or any help finding it later, or even much motivation to click on it.

As far as projects go, nearly everything is a project; so a "Projects" section of the forum would kind of nullify the purpose of having the various sections of the forum. You might have a project to restore a vintage computer you acquired. That should go in "Nostalgia." Or you might have a programmable-logic project, a hardware-build project, a software project, a project to build a 32-bit Forth model for the 65816, etc.. They're all projects, and there are the various sections of the forum to discuss them in.

The "Newbies" section should really be for newbies though. Here's the logic: If someone is new to object-oriented dispatch on the 65816 and is humble enough to post a question about it in "Newbies," and then someone who's a true newbie and is still learning what an address bus is comes and wants to ask questions, and he comes to the Newbies section and sees topics like the OOP one, he'll be intimidated. That's not what we want; so I might move the OOP topic to "Software."

Do make an effort to keep related things together, even if adding to an old topic. When you continue on an existing topic with relevant material, those who have already posted in that topic will get an email telling them that there's a new reply, even if the topic has sat dormant for years. That benefit is lost if you start a new topic just because the old one is old. Projects often go many years, as many of us go long periods of time without being able to work on a project. In my case, my work goes in waves that are many months long. I got to spend a few months on a project a year ago that I hope to get back to this spring.

Sam Gaskil used a topic as a blog for his video programmable-logic project. That's fine, and we were able to follow his progress and see how running into various problems prompted a change in plans. That's fine. It would get awfully splintered and clutter the forum if he started a new one when the direction he found himself going had changed a bit.

Most topics will evolve to some extent. That's fine. If a new subject comes up and could distract from a productive continuation of the original, then sure, start a new one. Otherwise, as stated above, there's value in keeping it together.

_________________
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: Tue Feb 09, 2021 6:44 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8484
Location: Midwestern USA
GARTHWILSON wrote:
It's not always easy to define when it's time to start a new topic...someone might be building hardware, get it going, and then build a language to run on it, which should be in a different topic, even a different section of the forum.

When I started on POC V1.0 (nearly 11 years ago) and decided to document my progress or lack thereof, I made the decision to create a single topic and add to it. The forum software makes that work because each time I or someone else adds a post to the topic, it will show up in the list of new posts. Hence one doesn't have to wade through previously-read material to get to the current state of the project.

I have faithfully followed that pattern, except in the few cases where a particular aspect of the project was such that it could be applicable to something more than just my project. An example of that was my separate topic on
wait-stating with clock stretching. Since wait-stating is something anyone building a high-speed system might need I felt it would be best to separately document my work on that.

I've also done separate topics on
filesystem development for the POC series' mass storage. Filesystems are generalized applications for organizing mass storage, so a separate topic made sense to me.

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


Top
 Profile  
Reply with quote  
PostPosted: Tue Feb 09, 2021 7:32 am 
Offline
User avatar

Joined: Mon Feb 01, 2021 1:07 am
Posts: 44
Location: Sydney, Australia
GARTHWILSON wrote:
...
Do make an effort to keep related things together, even if adding to an old topic
...

Will do, thank you for clarifying.
I had thought that my original post was going in few different directions, and figured since I would be discussing a different PLD chip this would justify a new topic.


GARTHWILSON wrote:
...
When you continue on an existing topic with relevant material, those who have already posted in that topic will get an email telling them that there's a new reply, even if the topic has sat dormant for years. That benefit is lost if you start a new topic just because the old one is old.
...

I had been wondering why I didn't get any email notifications to the replies in my new(second) topic. Is this the behavior of the notification system, i.e. a topic owner will get reply notifications to only one of his/her topics?


And Garth, thanks for the 6502 Primer, it's brilliant! I've learnt so much in such a short period of time.

_________________
Greetings Professor Falken.


Top
 Profile  
Reply with quote  
PostPosted: Tue Feb 09, 2021 7:48 am 
Offline
User avatar

Joined: Mon Feb 01, 2021 1:07 am
Posts: 44
Location: Sydney, Australia
BigDumbDinosaur wrote:
Just an opinion, but your I/O decoding is too granular. There is a tendency with beginners to try to use as much of the MPU's address space as possible for fear of "wasting" some. What often happens is the glue logic becomes convoluted and (if discrete) slow. Also, in order to achieve what you are proposing you'd have to hook up 12 of the MPU's 16 address lines to the GAL. Assuming you are using the 22V10, doing so would leave no inputs for anything else, a design decision you may come to regret later on.

Also, what is the purpose of having so much ROM? What all do you plan to put in there? My POC V1.0 and V1.1 units only have 8KB of ROM, yet I was able to fit a complete BIOS in there, along with a machine language monitor and support for SCSI hardware. In my POC V1.2 unit, I decided to give it 12KB of ROM, but that was the result of logic design convenience, not any particular need for more ROM.

Thirdly, there is no design advantage to inserting I/O into the middle of the ROM's address space and thus making ROM non-contiguous. Such a tactic could be useful if you were arranging so you could switch out part of the ROM and expose RAM in the same address space. In this case, however, that isn't possible, and interrupting ROM address space like that only complicates programming the ROM. If it were me, I'd move I/O down so ROM is contiguous to the top of address space and in the process, give yourself more RAM.

So to answer all your questions... beginner mistakes on my part!

Why am I using 32k of ROM? LOL, I thought I'd need as much RAM and ROM as possible. Last I'd read (some 10 years ago), a simple "Hello World" application in .NET takes 23MB in size (incl. all the required libraries). I understand well that assembly is a different world, but I have the mindset of being a commercial high-level developer for close to three decades. Thinking about this further, I'm going to initially go with 8k ROM, and adjust as I go. Also thanks heaps for the tip, I will keep the ROM contiguous to make the programming more straight-forwards, especially for someone at my level.

_________________
Greetings Professor Falken.


Top
 Profile  
Reply with quote  
PostPosted: Tue Feb 09, 2021 8:15 am 
Offline
User avatar

Joined: Mon Feb 01, 2021 1:07 am
Posts: 44
Location: Sydney, Australia
floobydust wrote:
Well, I opted for a 22V10 for a single glue logic. The extra resources (over the 16V8) provide for qualified Read and Write signals for RAM/ROM and other (non-65XX) I/O devices. I also went with 32-byte wide I/O selects (5 of them). I'm now using a Maxim DS1511 Realtime clock, which does have 32-byte wide addressing, albeit only 18 are actually used.

Be sure to input your defines into WinCUPL and see if it compiles correctly and if the simulator works. I had some really odd issues in WinCUPL with the 16V8. I'm using this on an adapter which breaks up a single 32-byte wide I/O select to drive said 1511 RTC, and a Compact Flash IDE device (both selects) and an upper byte bidirectional latch. Finally got it to compile and sim correctly, but it was an odd one.

Getting the 22V10 to work in WinCUPL wasn't that difficult... so I can only think that there's something odd about the 16V8 with WinCUPL... but again, depending on what you're doing with it, it might change.

Thanks for the info and the code - it will come handy soon. And I will definitely be going with a 22V10.

_________________
Greetings Professor Falken.


Top
 Profile  
Reply with quote  
PostPosted: Tue Feb 09, 2021 8:28 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8540
Location: Southern California
Firefox6502 wrote:
I had been wondering why I didn't get any email notifications to the replies in my new (second) topic. Is this the behavior of the notification system, i.e. a topic owner will get reply notifications to only one of his/her topics?

Unless you've changed something in your user information, you should be getting a notification anytime there's a reply posted following any of your posts, even if you're not the one who started the topic. If there are multiple replies on the same one, you'll get only the one email until you check in again IIRC.

Quote:
And Garth, thanks for the 6502 Primer, it's brilliant! I've learnt so much in such a short period of time.

You're welcome. I wrote it in its original form about 20 years ago to answer questions and problems that kept coming up on the forum, but I didn't have my own website yet, so it sat collecting dust until 2012. Then I blew the dust off and made some upgrades, and posted it. I make frequent updates on it. There was something recently that made me think I should add another whole page. People have asked about more-advanced stuff though, which would not fit in the category of "primer," ie, the basics to get you going. There are of course many other major features on my site, including ones with many pages, the stacks treatise having the second-most pages, with 19 plus appendices. I plan to post a lot more material, but it all takes so much time. I did most of it at times that my job was slow.

_________________
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: Tue Feb 09, 2021 8:44 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8484
Location: Midwestern USA
Firefox6502 wrote:
Why am I using 32k of ROM? LOL, I thought I'd need as much RAM and ROM as possible. Last I'd read (some 10 years ago), a simple "Hello World" application in .NET takes 23MB in size (incl. all the required libraries). I understand well that assembly is a different world, but I have the mindset of being a commercial high-level developer for close to three decades. Thinking about this further, I'm going to initially go with 8k ROM, and adjust as I go. Also thanks heaps for the tip, I will keep the ROM contiguous to make the programming more straight-forwards, especially for someone at my level.

One of the best features of 65C02 assembly language is its "economy of speech." Properly-written 65C02 assembly language programs tend to be succinct and fast-executing. This is in stark contrast to compiled languages, which tend to bloat up from attached libraries and limitations in trying to convert English-like statements into machine code. So you will be pleasantly amazed at how much 65C02 code you can stuff into 8KB of ROM.

BTW, here's a "Hello, world." program you can test after you get your machine going.


Code:
;print "Hello, world." on console
;
         ldy #0                ;string index
;
loop     lda hello,y           ;get from string
         beq done              ;null means end-of-string
;
         jsr putch             ;output char to console
         iny                   ;bump index &...
         bra loop              ;continue
;
done     brk                   ;function end (could be RTS instead)
;
;
;   text string...
;
hello    .byte "Hello, world!",$0d,$0a,$00

The above program is 14 bytes in length, not counting the actual text string. PUTCH would be defined as the entry pint for the function (subroutine) in your BIOS that writes a character to the console screen.

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


Last edited by BigDumbDinosaur on Tue Feb 09, 2021 8:52 am, edited 1 time in total.

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

All times are UTC


Who is online

Users browsing this forum: No registered users and 13 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: